Re: [patch] x86_*fence replaced by membar_ops(3)

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

On Thu, Jan 15, 2009 at 01:17:04PM +0100, Jean-Yves Migeon wrote:
> 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
> >uniprocessor system,
> 
> Alright
> 
> Well, considering the x86 memory model, I guess it is very tolerant, and 
> I got lucky during my build.sh run then.

Yes, it's not so easy to trigger the races, and it may not occur on
all CPUs. You'll see it when run Xen on SMP boxes, and some useage pattern
(such as heavy disk or network I/O)

> 
> 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 
> example).

I guess one day we'll want to change that. We want to make a difference between
barrier private to the kernel and barriers used in foreing interfaces
(Xen, or hardware drivers)

> 
> 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 is in some sense equivalent to a DMA. It's not a PCI adapter which is
accessing the data but the reader/writer is still accessing data
in an asynchronous way from the kernel POW.

> 
> >>[1] http://www.netbsd.org/~jym/membar_ops.diff
> >
> >This should not be committed as is.
> >
> >Thanks,
> 
> What should I do? Drop it for the x86 generic bus code, and keep it for 
> the Xen drivers?

No, membar_ops won't work for bus_dma/bus_space either. membar_ops are patched
to be NOP on UP kernels, still they're needed for interfaces with 
devices.

-- 
Manuel Bouyer, LIP6, Universite Paris VI.           
Manuel.Bouyer%lip6.fr@localhost
     NetBSD: 26 ans d'experience feront toujours la difference
--