* Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote: > On Thu, Dec 19, 2013 at 06:25:35PM +0100, Peter Zijlstra wrote: > > On Thu, Dec 19, 2013 at 06:07:41PM +0100, Ingo Molnar wrote: > > > Likewise, having a barrier before the MONITOR looks sensible as well. > > > > I again have to disagree, one would expect monitor to flush all that is > > required to start the monitor -- and it actually does so. As is > > testified by this extra CLFLUSH being called a bug workaround. > > SDM states that MONITOR is ordered like a LOAD, and a LOAD cannot > pass a previous STORE to the same address. Yes ... but you could argue that CLFLUSH is neither a load nor a store, it's a _cache sync_ operation, with its special ordering properties. > That said; there's enough holes in there to swim a titanic through, > seeing how MONITOR stares at an entire cacheline and LOAD/STORE > order is specified on location, whatever that means. I think assuming that MONITOR is ordered as a load or better is a pretty safe one (and in fact the Intel documentation seems to say so) - I'd say MONITOR is in micro-code and essentially snoops on cache events on that specific cache line, and loads the cache line on a snoop hit? Btw., what state is the cache line after a MONITOR instruction, is it loaded as shared, or as excusive? (exclusive would probably be better for performance.) Thanks, Ingo -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html