From owner-svn-src-user@FreeBSD.ORG Wed Nov 12 13:12:07 2008 Return-Path: Delivered-To: svn-src-user@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AABEF106575B; Wed, 12 Nov 2008 13:12:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (bigknife-pt.tunnel.tserv9.chi1.ipv6.he.net [IPv6:2001:470:1f10:75::2]) by mx1.freebsd.org (Postfix) with ESMTP id 454F98FC12; Wed, 12 Nov 2008 13:12:07 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [IPv6:::1]) (authenticated bits=0) by server.baldwin.cx (8.14.3/8.14.3) with ESMTP id mACDBNKA084446; Wed, 12 Nov 2008 08:12:01 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: "Attilio Rao" Date: Tue, 11 Nov 2008 12:14:21 -0500 User-Agent: KMail/1.9.7 References: <200811080202.mA822D0W098283@svn.freebsd.org> <200811101647.12258.jhb@freebsd.org> <3bbf2fe10811101440j26351593taccd2654f0ef4374@mail.gmail.com> In-Reply-To: <3bbf2fe10811101440j26351593taccd2654f0ef4374@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200811111214.21288.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [IPv6:::1]); Wed, 12 Nov 2008 08:12:01 -0500 (EST) X-Virus-Scanned: ClamAV 0.93.1/8620/Wed Nov 12 04:05:38 2008 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-2.0 required=4.2 tests=AWL,BAYES_00, DATE_IN_PAST_12_24,NO_RELAYS autolearn=no version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: src-committers@freebsd.org, Kip Macy , svn-src-user@freebsd.org Subject: Re: svn commit: r184759 - user/kmacy/HEAD_fast_multi_xmit/sys/net X-BeenThere: svn-src-user@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the experimental " user" src tree" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Nov 2008 13:12:07 -0000 On Monday 10 November 2008 05:40:41 pm Attilio Rao wrote: > 2008/11/10, John Baldwin : > > On Saturday 08 November 2008 11:53:53 am Attilio Rao wrote: > > > 2008/11/8, David Schultz : > > > > On Sat, Nov 08, 2008, Attilio Rao wrote: > > > > > Definitively, I'm not sure we need this. > > > > > We alredy have memory barriers you could exploit which just require a > > > > > "dummy" object. > > > > > > > > > > For example you could do: > > > > > flowtable_pcpu_unlock(struct flowtable *table, uint32_t hash) > > > > > { > > > > > > > > > > (void)atomic_load_acq_ptr(&dummy); > > > > > ... > > > > > > > > > > > > Memory barriers are cheaper than atomic ops. > > > > > > But this is an atomic op too. > > > > > > > Furthermore, there's different types of memory barriers > > > > (store/store, load/store, etc.), not just a generic mb(). Some > > > > architectures like sparc64 define all four, but only actually > > > > implement the varieties that are useful in improving performance. > > > > Take a look at what Solaris has here. > > > > > > > > I'm skeptical of trying to play clever tricks with these things > > > > outside of the code that implements synchronization > > > > primitives. Memory ordering is very hard to reason about, and we > > > > already have a lot of code, e.g., in libthr, that isn't correct > > > > under weak memory ordering. Moreover, the compiler can reorder > > > > loads and stores, and that just adds a whole new level of pain. > > > > > > _acq prefix is intended to not let reordering happening really. > > > man 9 atomic can explain how the acq and rel memory barriers work. > > > > > > _acq is not a full barrier, it's more of an 'lfence'. The mb() here is doing > > more of a _rel barrier ('sfence', etc.). > > Sure but the comment is still valid. > I don't see the point of such things when you can implement barriers > trough our atomic_* stuff. atomic_* stuff works when you are already doing a store. Doing a "dummy" store is quite a hack just to get a standalone memory barrier. There is a reason ia64 includes "acq" and "rel" variants of various instructions as well as a standalone "fence". One problem with Kip's change though is that it doesn't work on older x86 CPUs that don't have "sfence" (pre-PIII IIRC). I'm not sure if some of the lower-power x86 CPUs such as VIA, etc. support "sfence" either, though I think those are typically used in single-CPU setups. -- John Baldwin