Re: Why does membar_consumer() do anything on x86_64?

[Manuel Bouyer <bouyer%antioche.eu.org@localhost>]

On Thu, Jul 22, 2010 at 10:46:30AM -0700, Dennis Ferguson wrote:
> [...]
> 
> I don't doubt at all that you fixed a bug by inserting a memory barrier.
> What I would say, however, is that if you fixed this by inserting a
> call to membar_consumer() then you still have a bug since the reordering
> of loads against other loads is not something that x86 processors do,
> but that's the only thing that membar_consumer() promises to protect
> against.

It's a x86_lfence(), which on i386 is implemted with a lock prefix.
On amd64 it's a lfence instruction.
This was in the xen2 code, which got removed in HEAD.
For xen3, this is abstracted in arch/xen/include/xen3-public/io/ring.h,
which uses x86_mfence, x86_lfence and x86_sfence.
I'm almost sure that noone of these are a noop on linux.

> 
> This is precisely what I'm complaining about.  membar_consumer() does
> more than its man page says, and is relatively expensive to call.  In
> code on the x86 which only needs to protect against load/load
> misordering the current implementation of membar_consumer() is a waste.

I would be extremely carefull before claiming that membar_consumer() could
be a noop. Even if recent architecture manual says so, you'd also have to
check errata for every CPUs. I've had a very close look at the
errata^Wspeficiations updates for a certain Xeon revision, and there was
memory ordering bugs (though I don't remember the details).

-- 
Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference
--