Arjan van de Ven wrote:
quoted text
> 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
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/