monitor+mwait and volatile-ish

Konstantin Belousov kostikbel at gmail.com
Wed Sep 26 09:11:12 UTC 2012


On Wed, Sep 26, 2012 at 11:14:41AM +0300, Andriy Gapon wrote:
> 
> Typical x86 MONITOR+MWAIT is like this (taken from Intel manual):
> 
> EAX = Logical Address(Trigger)
> ECX = 0 (*Hints *)
> EDX = 0 (* Hints *)
> IF ( !trigger_store_happened) {
> 	MONITOR EAX, ECX, EDX
> 	IF ( !trigger_store_happened ) {
> 	MWAIT EAX, ECX
> 	}
> }
> 
> In FreeBSD we have this helper function for MONITOR:
> static __inline void
> cpu_monitor(const void *addr, u_long extensions, u_int hints)
> {
> 
>         __asm __volatile("monitor"
>             : : "a" (addr), "c" (extensions), "d" (hints));
> }
> 
> Now, let's assume that 'Trigger' is a global variable and
> 'trigger_store_happened' is a check for a particular value in this variable.
> 
> Then, with current state of matters, we must either declare the global variable
> to be volatile or use a volatile cast in the second IF.  Otherwise, a compiler
> is free to assume that the variable doesn't change between the first and the
> second IF and drop the second IF altogether.  And that would make MONITOR+MWAIT
> to miss an event if it happens "between" the first check and MONITOR.
> 
> So what's my point.
> - using volatile variable with cpu_monitor requires DEVOLATILE to silence
> compiler warning about discarding volatile; this is unnecessary code bloat
> - adding volatile cast in the checks is easy to forget and adds code bloat
> 
> Possible improvements:
> - make the argument of cpu_monitor be 'const volatile void *', the most
> permissive type; this would also be a hint that variable should be volatile
> - add some magic dust to cpu_monitor that would tell compiler to not cache
>   the variable; right now I can only think of the "memory" constraint, but it
>   seems to be too big of a hummer
> 
> What do you think about this?

You might claim that the asm writes to *addr by specifying it in the
output constraint. This should fool the compiler into reload *addr after
the monitor execution.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-hackers/attachments/20120926/b2d15606/attachment.pgp


More information about the freebsd-hackers mailing list