Re: [PATCH 03 of 36] x86: add memory barriers to wrmsr

Jeremy Fitzhardinge
2008-06-25T21:09:23Z

Arjan van de Ven wrote:
> it's more readable for several of these cases to stick a barrier(); in
> front and after it to be honest; that makes it more explicit that
> these are deliberate compiler barriers rather than "actual" memory
> access...
>
>

I suppose, though I would be inclined to put the barriers in the wrmsr
macro itself to act as documentation. Either way, I don't think there's
any legitimate reason to let the compiler reorder things around a wrmsr,
and it should be an inherent property of the macro, rather than relying
on ad-hoc barriers where it gets used. After all, that's a fairly
accurate reflection of how the micro-architecture treats wrmsr...

J