From owner-svn-src-user@FreeBSD.ORG Sat Nov 8 16:53:56 2008 Return-Path: <owner-svn-src-user@FreeBSD.ORG> 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 277F5106567C; Sat, 8 Nov 2008 16:53:56 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: from fg-out-1718.google.com (fg-out-1718.google.com [72.14.220.152]) by mx1.freebsd.org (Postfix) with ESMTP id 28B728FC16; Sat, 8 Nov 2008 16:53:54 +0000 (UTC) (envelope-from asmrookie@gmail.com) Received: by fg-out-1718.google.com with SMTP id l26so1479615fgb.35 for <multiple recipients>; Sat, 08 Nov 2008 08:53:53 -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:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references :x-google-sender-auth; bh=026roWEMMFdDDGLPKrZix30bWgqP8kAXrx9tobGTFFg=; b=xAEQMkF6bhfuOtwarVxwyVTD/l7T1m2pWp6BNjR3SQPSt9VKuOOt5XJlJ60B34Q6Ae Rm+M21kIVRkayj8gUfyq0QvFvQcLjZII9x5KsBlIMJdVwU0+Is+V3cCNJTqtvFTBgvuY qkQGYDpFGj85Rb3854LpBzqw1NcrIA39rfSAY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:sender:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references:x-google-sender-auth; b=mcdrOQzMnKSRq0woptn4bOoMHWF6nZUTZcNRZf39FI+J4GyL7SG2L5JKgZcdXaliTH jm/SlhB+Sx9xQeg0vgSwHxnK1H1cGWSwbXLaA6OYJaA/m4yWKo4KUJXkY6bMXESjPic4 2rdBPjyH7lABMl62KFrpgSx5Fh/qVR0L9c780= Received: by 10.86.4.14 with SMTP id 14mr5256750fgd.27.1226163233975; Sat, 08 Nov 2008 08:53:53 -0800 (PST) Received: by 10.86.2.18 with HTTP; Sat, 8 Nov 2008 08:53:53 -0800 (PST) Message-ID: <3bbf2fe10811080853j3ebf5b2em29ebdd2a7187ff67@mail.gmail.com> Date: Sat, 8 Nov 2008 17:53:53 +0100 From: "Attilio Rao" <attilio@freebsd.org> Sender: asmrookie@gmail.com To: "Attilio Rao" <attilio@freebsd.org>, "Kip Macy" <kmacy@freebsd.org>, src-committers@freebsd.org, svn-src-user@freebsd.org In-Reply-To: <20081108163006.GA5256@zim.MIT.EDU> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <200811080202.mA822D0W098283@svn.freebsd.org> <3bbf2fe10811080530t6846fce8mdf62f755c1864ea2@mail.gmail.com> <20081108163006.GA5256@zim.MIT.EDU> X-Google-Sender-Auth: 397ef25b889c4b12 Cc: 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" <svn-src-user.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-user>, <mailto:svn-src-user-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/svn-src-user> List-Post: <mailto:svn-src-user@freebsd.org> List-Help: <mailto:svn-src-user-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/svn-src-user>, <mailto:svn-src-user-request@freebsd.org?subject=subscribe> X-List-Received-Date: Sat, 08 Nov 2008 16:53:56 -0000 2008/11/8, David Schultz <das@freebsd.org>: > 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. Thanks, Attilio -- Peace can only be achieved by understanding - A. Einstein