From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753320AbbETJM3 (ORCPT ); Wed, 20 May 2015 05:12:29 -0400 Received: from cantor2.suse.de ([195.135.220.15]:55276 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753295AbbETJMR (ORCPT ); Wed, 20 May 2015 05:12:17 -0400 Date: Wed, 20 May 2015 11:12:13 +0200 From: Borislav Petkov To: Ingo Molnar , Huang Rui Cc: 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: <20150520091213.GA3645@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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150520085520.GA8566@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 10:55:20AM +0200, Ingo Molnar wrote: > Does it use it to decide how 'deep' a sleep it will go into, i.e. > larger timeouts cause longer entry and exit latencies? That's what the HLT thing does. Cores go into C1 and then at some point (hysteresis, etc) the whole core complex enters C1E. The MWAIT* should be used for only shorter sleeps as it remains in C1. IMHO, of course. But the problem there is another: what happens if the timeout fires, you wake up and see that you can remain idle? Do HLT? Do another MWAITX round? This means you have an additional unnecessary wakeup which costs. > I suppose it's also the case that if an interrupt arrives _before_ the > expected timeout then MWAITX will try to exit immediately, it won't > wait until the timeout, right? I'd assume so - I mean, it must, right. BUT!, in talking to Andy about it last night on IRC, he pointed out that when using acpi_idle, we never come to calling x86_idle() and from looking quickly at cpuidle_idle_call(), that still might be the case as we go to use_default only when there's an error with the cpuidle driver or so. So Rui, before you go and do more work on it, you should probably analyze what cpuidle exactly does (if you haven't done so yet). And on AMD we do use acpi_idle - at least on my F15h box that is the case: $ grep . /sys/devices/system/cpu/cpuidle/current_* /sys/devices/system/cpu/cpuidle/current_driver:acpi_idle /sys/devices/system/cpu/cpuidle/current_governor_ro:menu Thanks. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --