From owner-svn-src-head@freebsd.org Mon Dec 10 23:48:06 2018 Return-Path: Delivered-To: svn-src-head@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 C07E51336A43; Mon, 10 Dec 2018 23:48:06 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id C4CEC74101; Mon, 10 Dec 2018 23:48:05 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id wBANlsvg071368 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 11 Dec 2018 01:47:57 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua wBANlsvg071368 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id wBANlsrX071367; Tue, 11 Dec 2018 01:47:54 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 11 Dec 2018 01:47:54 +0200 From: Konstantin Belousov To: John Baldwin Cc: Warner Losh , Kevin Bowling , Mateusz Guzik , Ian Lepore , svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers , scottl@freebsd.org Subject: Re: svn commit: r341682 - head/sys/sys Message-ID: <20181210234754.GD60291@kib.kiev.ua> References: <201812071205.wB7C5BvA038350@repo.freebsd.org> <1544206201.1860.288.camel@freebsd.org> <45f85061-2633-852c-3cc0-41f64d51e4f0@FreeBSD.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <45f85061-2633-852c-3cc0-41f64d51e4f0@FreeBSD.org> User-Agent: Mutt/1.11.1 (2018-12-01) X-Spam-Status: No, score=0.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM,FREEMAIL_REPLY, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on tom.home X-Rspamd-Queue-Id: C4CEC74101 X-Spamd-Result: default: False [-4.92 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; HAS_XAW(0.00)[]; R_SPF_SOFTFAIL(0.00)[~all]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MX_GOOD(-0.01)[cached: alt3.gmail-smtp-in.l.google.com]; NEURAL_HAM_SHORT(-0.78)[-0.781,0]; RCPT_COUNT_SEVEN(0.00)[9]; IP_SCORE(-2.13)[ip: (-2.65), ipnet: 2001:470::/32(-4.48), asn: 6939(-3.42), country: US(-0.09)]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_TLS_LAST(0.00)[]; DMARC_POLICY_SOFTFAIL(0.10)[gmail.com : No valid SPF, No valid DKIM,none] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Dec 2018 23:48:07 -0000 On Mon, Dec 10, 2018 at 02:15:20PM -0800, John Baldwin wrote: > On 12/8/18 7:43 PM, Warner Losh wrote: > > > > > > On Sat, Dec 8, 2018, 8:36 PM Kevin Bowling wrote: > > > > On Sat, Dec 8, 2018 at 12:09 AM Mateusz Guzik > 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. It is worse. All atomics that acess the same location must use the same lock. Otherwise, you could observe torn writes and out of thin air values. Since you cannot know in advance which locations are acceses by the locked variant, all freebsd atomics ops have to be switched to locked variant on the architecture.