Date: Sat, 8 Nov 2008 11:30:06 -0500 From: David Schultz <das@FreeBSD.ORG> To: Attilio Rao <attilio@FreeBSD.ORG> Cc: src-committers@FreeBSD.ORG, Kip Macy <kmacy@FreeBSD.ORG>, svn-src-user@FreeBSD.ORG Subject: Re: svn commit: r184759 - user/kmacy/HEAD_fast_multi_xmit/sys/net Message-ID: <20081108163006.GA5256@zim.MIT.EDU> In-Reply-To: <3bbf2fe10811080530t6846fce8mdf62f755c1864ea2@mail.gmail.com> References: <200811080202.mA822D0W098283@svn.freebsd.org> <3bbf2fe10811080530t6846fce8mdf62f755c1864ea2@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20081108163006.GA5256>