Re: CVS commit: src/sys/arch/xen/xen

[Lennart Augustsson <lennart%augustsson.net@localhost>]

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.

        -- Lennart