From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ingo Molnar Subject: Re: [PATCH] x86 idle: repair large-server 50-watt idle-power regression Date: Thu, 19 Dec 2013 19:18:12 +0100 Message-ID: <20131219181812.GC32508@gmail.com> References: <20131219122257.GC11279@gmail.com> <52B316FF.50906@zytor.com> <20131219160210.GA28426@gmail.com> <52B31B21.6010901@zytor.com> <20131219162136.GM16438@laptop.programming.kicks-ass.net> <52B323BE.7090108@zytor.com> <20131219170741.GB30382@gmail.com> <20131219172535.GN16438@laptop.programming.kicks-ass.net> <20131219175037.GK2480@laptop.programming.kicks-ass.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mail-wg0-f52.google.com ([74.125.82.52]:61946 "EHLO mail-wg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754690Ab3LSSSQ (ORCPT ); Thu, 19 Dec 2013 13:18:16 -0500 Content-Disposition: inline In-Reply-To: <20131219175037.GK2480@laptop.programming.kicks-ass.net> Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Peter Zijlstra Cc: "H. Peter Anvin" , Len Brown , x86@kernel.org, linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org, Len Brown , stable@vger.kernel.org, Linus Torvalds , Thomas Gleixner , Mike Galbraith , Borislav Petkov * Peter Zijlstra 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