From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752349AbbETKuh (ORCPT ); Wed, 20 May 2015 06:50:37 -0400 Received: from cantor2.suse.de ([195.135.220.15]:35276 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751159AbbETKuf (ORCPT ); Wed, 20 May 2015 06:50:35 -0400 Date: Wed, 20 May 2015 12:50:32 +0200 From: Borislav Petkov To: Ingo Molnar Cc: Huang Rui , Len Brown , "Rafael J. Wysocki" , Thomas Gleixner , x86@kernel.org, linux-kernel@vger.kernel.org, Fengguang Wu , Aaron Lu , Tony Li Subject: Re: [RFC PATCH 2/4] x86, mwaitt: introduce mwaitx idle with a configurable timer Message-ID: <20150520105032.GD3645@pd.tnic> References: <1432022472-2224-1-git-send-email-ray.huang@amd.com> <1432022472-2224-3-git-send-email-ray.huang@amd.com> <20150519113121.GD4819@pd.tnic> <20150520085520.GA8566@gmail.com> <20150520091213.GA3645@pd.tnic> <20150520102258.GA21245@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150520102258.GA21245@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 20, 2015 at 12:22:58PM +0200, Ingo Molnar wrote: > Well, HLT does not get any hint from the OS how long the idling is > expected to last. MWAIT on AMD doesn't either: "EAX specifies optional hints for the MWAIT instruction. There are currently no hints defined and all bits should be 0. Setting a reserved bit in EAX is ignored by the processor." I don't know about MWAITX though as I haven't seen any official doc yet. > Another MWAITX round - we've got no crystal ball, so the hint might be > wrong if an external event occurs that we did not anticipate. So if we end up doing a bunch of MWAITX rounds instead of HLT and MWAITX saves less power than HLT, then we practically are worse. I think the idea with MWAITX is to use it to sleep only when you know the timeout would be shorter - whatever "shorter" means - and thus you can save yourself the idle entry/exit latency. If you keep waking up due to timeout ending - which with u32 in EBX will be ~1sec on a 4GHz core, or 2 on a 2GHz core - and your MWAITX C-state is worse wrt power consumption than your HLT state, then you lose. And your MWAITX C-state *is* worse currently, see below. > I don't think MWAITX will wake up in itself. (If yes then it's > essentially a timer in disguise and needs a whole different approach!) I mean when the MWAITX timeout expires. When it does, we wake up. Also, normal MWAIT allows for interrupts to wake it up: "ECX specifies optional extensions for the MWAIT instruction. The only extension currently defined is ECX bit 0, which allows interrupts to wake MWAIT, even when eFLAGS.IF = 0. Support for this extension is indicated by a feature flage returned by the CPUID instruction." > The question would be: on systems that provide ACPI idle but also have > MWAITX support, which one behaves better on the hardware side? I'd venture a guess here that the ACPI side should be using all C-states available (think of other OSes and having optimal power savings there) and MWAITX would be worse or the same. Right now it is entering some funny state between C0 and C1 reportedly: "But on AMD platform, mwaitx/mwait cannot go to C1 or C1E like intel. The power consumption of waiting phase is somewhere in between (C0 and C1). Actually, it's still in C0 but less power consumption than normal C0." So my thinking currently is - provided we want to use it at all: * Use MWAITX on entry to idle, considering that on a busy system, the statistical probability of this sleep timeout to be small, is high. * When the timeout expires and we wake up and realize there's still nothing to do, we do HLT. But all that is pointless if we end up in acpi_idle anyway... -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --