Re: [RFC PATCH] introduce sys_membarrier(): process-wide memorybarrier (v3a)

[Peter Zijlstra]

On Mon, 2010-01-11 at 15:52 -0500, Mathieu Desnoyers wrote:

> >  - receiving an IPI implies an mb, or
> 
> So, I think that if we have other concurrent IPI requests sent, we have
> no guarantee that the IPI handler will indeed issue the memory barrier 
> _after_ we added the entry to the list. The list itself is synchronized
> with a spin lock-irqoff, but not with an explicit memory barrier. Or am
> I missing a subtlety here ?

Linus once said ( http://lkml.org/lkml/2009/2/18/145 ) :

"... at least on x86, taking an interrupt should be a serializing 
event, so there should be no reason for anything on the receiving side."

But he also notes that in generic this does not need to be so.

My question was more generic than: is this currently the case for x86,
though, I was wondering if we want this to be true and should therefore
make it so.

However re-reading the referenced discussion I think we might not want
to force it in generic because it might cause unneeded slow-down.

> >  - enter/leave kernelspace implies an mb
> > ?
> 
> On x86, iret is a serializing instruction. However, I haven't found any
> information saying that int 0x80 nor sysenter/sysexit are serializing
> instructions. And there seem to be no explicit mfence in x86 entry_*.S
> (except a 64-bit gs swap workaround). So I'm tempted to answer: no,
> entry/return kernelspace does not seem to imply a mb on x86. 

Right, there's some TIF_flags we can play with, but simply executing the
mb is a much simpler (and clearer) alternative.



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/