[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: [patch] x86_*fence replaced by membar_ops(3)
Andrew Doran wrote:
On Wed, Jan 14, 2009 at 07:55:09PM +0100, Jean-Yves Migeon wrote:
membar_foo() are for memory barriers in a multiprocessor system.
The fence functions are used for memory barriers in respect of DMA even on a
Well, considering the x86 memory model, I guess it is very tolerant, and
I got lucky during my build.sh run then.
For my personal culture, any way to stress or trigger a race in such a case?
or in a system like Xen where the NetBSD kernel is
uniprocessor but the monitor can be on a different CPU.
Hmm, I do not understand this one. Under Xen, even for a UP domain, we
do not alter the membar_ops() primitives, they keep their MP definition
(there is no call to x86_patch() that patches the lock prefixes, for
Why should the fences be any different than their membar_ops(3)
equivalent here? In Xen drivers, there is no DMA, we are just bouncing
data back and forth through shared pages. From my PoV, the membar_ops do
make sense in this case as synchronisation primitives.
This should not be committed as is.
What should I do? Drop it for the x86 generic bus code, and keep it for
the Xen drivers?
Many thanks for all who responded. Cheers,
Main Index |
Thread Index |