Date: Wed, 26 Sep 2012 12:10:57 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Andriy Gapon <avg@freebsd.org> Cc: freebsd-hackers <freebsd-hackers@freebsd.org> Subject: Re: monitor+mwait and volatile-ish Message-ID: <20120926091057.GH35915@deviant.kiev.zoral.com.ua> In-Reply-To: <5062B971.30203@FreeBSD.org> References: <5062B971.30203@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--a8sldprk+5E/pDEv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Sep 26, 2012 at 11:14:41AM +0300, Andriy Gapon wrote: >=20 > Typical x86 MONITOR+MWAIT is like this (taken from Intel manual): >=20 > EAX =3D Logical Address(Trigger) > ECX =3D 0 (*Hints *) > EDX =3D 0 (* Hints *) > IF ( !trigger_store_happened) { > MONITOR EAX, ECX, EDX > IF ( !trigger_store_happened ) { > MWAIT EAX, ECX > } > } >=20 > In FreeBSD we have this helper function for MONITOR: > static __inline void > cpu_monitor(const void *addr, u_long extensions, u_int hints) > { >=20 > __asm __volatile("monitor" > : : "a" (addr), "c" (extensions), "d" (hints)); > } >=20 > Now, let's assume that 'Trigger' is a global variable and > 'trigger_store_happened' is a check for a particular value in this variab= le. >=20 > Then, with current state of matters, we must either declare the global va= riable > to be volatile or use a volatile cast in the second IF. Otherwise, a com= piler > 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. >=20 > 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 >=20 > 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 volati= le > - 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, bu= t it > seems to be too big of a hummer >=20 > 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. --a8sldprk+5E/pDEv Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAlBixqEACgkQC3+MBN1Mb4g6hwCdHLujvZ0OezxypmrLw8izSFsA 3WsAn1NLKzqqdKnwjmqxY67Sx+HuLx49 =dBY0 -----END PGP SIGNATURE----- --a8sldprk+5E/pDEv--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120926091057.GH35915>