CLFLUSH is only (guaranteed to be) ordered with respect to MFENCE according to the SDM. Ingo Molnar <mingo@xxxxxxxxxx> wrote: > >* 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 -- Sent from my mobile phone. Please pardon brevity and lack of formatting. -- 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