Port-amd64 archive

[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
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.

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

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.

[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?

Many thanks for all who responded. Cheers,

--
Jean-Yves Migeon
jeanyves.migeon%free.fr@localhost



Home | Main Index | Thread Index | Old Index