From owner-svn-src-head@freebsd.org Fri Apr 26 10:22:36 2019 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 2141E158FC71; Fri, 26 Apr 2019 10:22:36 +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 826D48D019; Fri, 26 Apr 2019 10:22:35 +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 x3QAMQRi027894 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Apr 2019 13:22:29 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua x3QAMQRi027894 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id x3QAMP9f027893; Fri, 26 Apr 2019 13:22:25 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 26 Apr 2019 13:22:25 +0300 From: Konstantin Belousov To: Bruce Evans Cc: Mark Johnston , Wojciech Macek , Wojciech Macek , src-committers , svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r346593 - head/sys/sys Message-ID: <20190426102225.GQ12936@kib.kiev.ua> References: <201904230636.x3N6aWQK057863@repo.freebsd.org> <20190425040817.GA3789@spy> <20190425082222.GJ12936@kib.kiev.ua> <20190426060456.GA59853@spy> <20190426073836.GP12936@kib.kiev.ua> <20190426074759.GA2695@spy> <20190426195450.B932@besplex.bde.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190426195450.B932@besplex.bde.org> User-Agent: Mutt/1.11.4 (2019-03-13) X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, 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-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: Fri, 26 Apr 2019 10:22:36 -0000 On Fri, Apr 26, 2019 at 08:04:29PM +1000, Bruce Evans wrote: > On Fri, 26 Apr 2019, Mark Johnston wrote: > > > On Fri, Apr 26, 2019 at 10:38:36AM +0300, Konstantin Belousov wrote: > >> On Fri, Apr 26, 2019 at 02:04:56AM -0400, Mark Johnston wrote: > >>> On Thu, Apr 25, 2019 at 11:22:22AM +0300, Konstantin Belousov wrote: > >>>> On Thu, Apr 25, 2019 at 07:38:21AM +0200, Wojciech Macek wrote: > >>>>> Intel does not reorder reads against the condition "if" here. I know for > >>>>> sure that ARM does, but therestill might be some other architectures that > >>>>> also suffers such behavior - I just don't have any means to verify. > >>>>> I remember the discussion for rS302292 where we agreed that this kind of > >>>>> patches should be the least impacting in perfomrance as possible. Adding > >>>>> unconditional memory barrier causes significant performance drop on Intel, > >>>>> where in fact, the issue was never seen. > >>>>> > >>>> Atomic_thread_fence_acq() is nop on x86, or rather, it is compiler memory > >>>> barrier. If you need read/read fence on some architectures, I am sure > >>>> that you need compiler barrier on all. > >>> > >>> To add a bit, one reason to prefer atomic(9) to explicit fences is > >>> precisely because it issues fences only when required by a given > >>> CPU architecture. There is no "unconditional memory barrier" added by > >>> the diff even without the #ifdef. > >> Well, atomic_thread_fence_acq() is the explicit fence. And on x86 it > >> does add unconditional compiler memory barrier. > > > > I only mean that with atomic_thread_fence_acq() on x86, the CPU does not > > see any fences. > > > > Based on the original commit it seems that a compiler barrier is > > required on all platforms, at a minimum. > > buf_ring.h has some volatile variables which might give sufficient barriers. > But no one knows what volatile does, so reasoning about it is even harder > than reasoning about ordering from atomic ops. I think the volatiles give > program order for the volatile variables only (plus ordering of other variables > from dependencies on the volatile variables), while the compiler barrier > gives program order for all variables. No, volatile does not give any ordering. For gcc-like compilers, documentation implies that the volatile accesses are guarenteed to occur, i.e. they cannot be optimized out. We use volatiles to implement relaxed atomics in atomic(9) API. For Java, volatile reads have acquire semantic, and volatile writes are releases.