From owner-svn-src-user@FreeBSD.ORG Mon Nov 10 22:40:44 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 C2CA71065673 for ; Mon, 10 Nov 2008 22:40:44 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from yx-out-2324.google.com (yx-out-2324.google.com [74.125.44.30]) by mx1.freebsd.org (Postfix) with ESMTP id 69AEE8FC2A for ; Mon, 10 Nov 2008 22:40:44 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by yx-out-2324.google.com with SMTP id 8so1022980yxb.13 for ; Mon, 10 Nov 2008 14:40:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:sender :to:subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=KYZjw9475yDf0aTRTsuxZvlgETr823+uddZVY3XIEfA=; b=sny9rqXBcZZ0u6fwuGUkvWW/fZbcMrmKuh+nfQS5+GvA04lYySNXB+hxJRu5rS1udi 7B5cZ/Isr3b4ymG7Dtloq2XRKH+rX1o14xDt98n9yRNIvZCay4zOR2BevNmcupk/AfMk ZKSsKnuFavYcPot3z+OjCB/6MJ2Hpa6LHIctc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=SbJDY796/4QmqVeyq5Qj6mlCw9MV8KsyqTx3/kHRcj+kdILODkEiEGQtd8R9WFNGWs vsChaMLCmR1aVAdMCR6KcPve/3gNWyLVy9IQPtq7E3pgBEA8d6jEOIHajfbdJlyw3Ws0 1X/UOEtIoKRUqZkyOL5iHX/v3OhxKljNE5qHg= Received: by 10.103.227.10 with SMTP id e10mr4089666mur.30.1226356841536; Mon, 10 Nov 2008 14:40:41 -0800 (PST) Received: by 10.103.239.14 with HTTP; Mon, 10 Nov 2008 14:40:41 -0800 (PST) Message-ID: <3bbf2fe10811101440j26351593taccd2654f0ef4374@mail.gmail.com> Date: Mon, 10 Nov 2008 23:40:41 +0100 From: "Attilio Rao" Sender: asmrookie@gmail.com To: "John Baldwin" In-Reply-To: <200811101647.12258.jhb@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811080202.mA822D0W098283@svn.freebsd.org> <20081108163006.GA5256@zim.MIT.EDU> <3bbf2fe10811080853j3ebf5b2em29ebdd2a7187ff67@mail.gmail.com> <200811101647.12258.jhb@freebsd.org> X-Google-Sender-Auth: 2b18bc12ac166789 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: Mon, 10 Nov 2008 22:40:44 -0000 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. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein