From owner-svn-src-all@freebsd.org Tue Dec 11 00:55:16 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CFC29130B220 for ; Tue, 11 Dec 2018 00:55:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1C43877569 for ; Tue, 11 Dec 2018 00:55:16 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qk1-x731.google.com with SMTP id r71so7665227qkr.10 for ; Mon, 10 Dec 2018 16:55:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Z5GhONhV94FT63PmsOX4BMTG6qfiDfYxKLXvRQzNy2U=; b=yTluxTzEt/uloPOPV4Iw0Kvz6E4c2ZOIJCV63yGSdXcwUzrg8BdA0z9gElChHE3gp0 2YWOKJB4euE4qYP58YeryNTkzksLjxDqarshzDfbfNGNuqQohzE5ojSd6v2e/JkDkg+D sYl/ZPI3otcEHNc3/7+mkBqnY8QazKHL+wpos0poWWZ89er5X1DFg62Ojllk4W29UWtm vEXZZWZVg9MfFtCVLytEiz7NF/S6aCG6LZHVSUj6klVECeihn1meh8IaVBMRzXgm5jkv mFEvNVilRPV40hyRSg6nbmywSYigf12bn98U2RxQ18Yn5VDr8ULkCubgeizrTMXUp/Wc aObw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Z5GhONhV94FT63PmsOX4BMTG6qfiDfYxKLXvRQzNy2U=; b=jPB1H4VqkE7BcpIbyfoywTZjxP95DMLynPdN3NM5JPh7cqYxKf2BLKWBZvx5nDz9Xd vtTbQ0o6OIt+TmHNOZGOT4WzhGOMLdWbugfaP9P/TuX9NpKX0wkQpIhWtUfC3fHckaYc uUJfJ6R6ZJPRC5aN/ZSWdD6hrKXZN9px9NRcnxIuwlJzj179kMD4/B5E+wRCc0VkdIAq u1INJ8ceESBbGpCSkQVXgILhYbCwhEw7eTm7O9ubCHoACfIvhKm4s4NUB48O7qtW4Zrd drBYySGJmN2i0aMF+cbHxlDm3twO8LdeNWgKb/k8UgDMvnTGy4RmFrXnpW46ATiI7W2A zOBQ== X-Gm-Message-State: AA+aEWa+3AZZsFxazwIjjasPIuigrMMEx+hbXP+//uMqbRKUmWiqkx2A odAh1NqNJNwWWkaRYWc30AlRqUezgOAOw23X86eJ7w== X-Google-Smtp-Source: AFSGD/X26JGPQTSvbaemE9VlLpCtO98WUwnky4GKxUMDKzDxz73/ny3BPbljfD4qEfo4++Y9wxFnAnPHd3PmkXLrC8k= X-Received: by 2002:a37:6c05:: with SMTP id h5mr13028212qkc.175.1544489715378; Mon, 10 Dec 2018 16:55:15 -0800 (PST) MIME-Version: 1.0 References: <201812071205.wB7C5BvA038350@repo.freebsd.org> <1544206201.1860.288.camel@freebsd.org> <45f85061-2633-852c-3cc0-41f64d51e4f0@FreeBSD.org> <1544486233.1860.343.camel@freebsd.org> In-Reply-To: From: Warner Losh Date: Mon, 10 Dec 2018 17:55:01 -0700 Message-ID: Subject: Re: svn commit: r341682 - head/sys/sys To: Justin Hibbits Cc: Ian Lepore , John Baldwin , Kevin Bowling , Mateusz Guzik , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers , scottl@freebsd.org X-Rspamd-Queue-Id: 1C43877569 X-Spamd-Result: default: False [-4.73 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998,0]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.91)[-0.906,0]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-all@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; MX_GOOD(-0.01)[cached: ALT1.aspmx.l.google.com]; RCPT_COUNT_SEVEN(0.00)[9]; RCVD_IN_DNSWL_NONE(0.00)[1.3.7.0.0.0.0.0.0.0.0.0.0.0.0.0.0.2.0.0.4.6.8.4.0.b.8.f.7.0.6.2.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; FREEMAIL_TO(0.00)[gmail.com]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-1.81)[ip: (-6.18), ipnet: 2607:f8b0::/32(-1.52), asn: 15169(-1.27), country: US(-0.09)]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Server: mx1.freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Dec 2018 00:55:17 -0000 On Mon, Dec 10, 2018, 5:27 PM Justin Hibbits > > On Mon, Dec 10, 2018, 17:57 Ian Lepore >> On Mon, 2018-12-10 at 14:15 -0800, John Baldwin wrote: >> > On 12/8/18 7:43 PM, Warner Losh wrote: >> > > >> > > >> > > >> > > On Sat, Dec 8, 2018, 8:36 PM Kevin Bowling > > > m wrote: >> > > >> > > On Sat, Dec 8, 2018 at 12:09 AM Mateusz Guzik > > > m > wrote: >> > > >> > > > >> > > > Fully satisfying solution would be that all architectures get >> > > 64-bit >> > > > ops, even if in the worst case they end up taking a lock. >> > > Then >> > > > subsystems would not have to ifdef on anything. However, >> > > there >> > > > was some opposition to this proposal and I don't think this >> > > is >> > > > important enough to push. >> > > >> > > Mateusz, >> > > >> > > Who is opposing this particular polyfill solution? Scott Long >> > > brought >> > > up a situation in driver development where this would be useful >> > > as >> > > well. The polyfills lower the cognitive load and #ifdef soup >> > > which >> > > are the right call here regardless of performance on toy ports. >> > > >> > > >> > > I don't recall seeing the opposition either. It would have to be a >> > > global lock for all 64bit atomics.... but I think it would only be >> > > 2 atomics on those architectures. >> > It would have to be a spin lock, so in the case of unrl you would be >> > trading >> > an operation on one of N regular mutexes for a single spin lock that >> > was >> > also contested by other things. This would be pretty crappy. For >> > drivers >> > that aren't actually used on platforms without 32-bit atomics we can >> > simply >> > not build them in sys/modules/Makefile or not put them in >> > GENERIC. For >> > something in the core kernel like unrl I think we will have to do >> > what >> > Mateusz has done here. >> > >> >> On a single-core system all you need to implement 64-bit atomics in the >> kernel is to disable interrupts around using normal load/store >> operations on the values. Do we have any platforms that are SMP but >> don't have hardware primitives for 64-bit atomics? >> >> -- Ian >> > > There were some dual processor G4 machines. I have one. It doesn't have > 64 bit atomics. > There is a 32 bit mips machine like this as well. For drivers it's not too bad, but for core functions in the MI part of the kernel, all known implementations super duper suck. Warner >