Subject: Re: CVS commit: src/sys/arch/xen/xen
To: Manuel Bouyer <firstname.lastname@example.org>
From: Lennart Augustsson <email@example.com>
Date: 03/27/2005 01:23:20
Manuel Bouyer wrote:
> On Sun, Mar 27, 2005 at 12:54:48AM +0100, Lennart Augustsson wrote:
>>>This would probablt be a good idea, but isn't __insn_barrier() a
>>>gcc builtin ?
>>Would that really be correct? I thought __insn_barries() was there
>>to stop gcc from reordering instructions, whereas x86_lfence() is
>>there to stop the processor from reordering loads and stores.
> I think we want a MI function to stop the processor from reordering
> instructions too. There is potentially a similar problem in the esiop(4)
> driver than the one I had with xen. I could abuse bus_space_barrier()
> for this but it's not quite right either.
> If we don't want the compiler to reorder instructions, I don't think we want
> to CPU to do it.
You may want to disallow the compiler to reorder, but allow the CPU to.
E.g., when programming with threads on a single CPU. The CPU reordering
(on an x86) never changes how the processor sees the memory if it is the
only client of the memory.
So I think there is a case for both. And yes, of course we want MI ways
of doing it. There is a whole range of possible fences one can imagine
and they carry different costs depending on the platform.