From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755507AbbEUOVT (ORCPT ); Thu, 21 May 2015 10:21:19 -0400 Received: from mail-bl2on0132.outbound.protection.outlook.com ([65.55.169.132]:44694 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753915AbbEUOVR (ORCPT ); Thu, 21 May 2015 10:21:17 -0400 Authentication-Results: spf=none (sender IP is 165.204.84.222) smtp.mailfrom=amd.com; intel.com; dkim=none (message not signed) header.d=none; X-WSS-ID: 0NOPEIX-08-YCL-02 X-M-MSG: Date: Thu, 21 May 2015 22:15:17 +0800 From: Huang Rui To: Borislav Petkov CC: Ingo Molnar , Len Brown , "Rafael J. Wysocki" , Thomas Gleixner , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , Fengguang Wu , "Aaron Lu" , "Li, Tony" Subject: Re: [RFC PATCH 2/4] x86, mwaitt: introduce mwaitx idle with a configurable timer Message-ID: <20150521141516.GA22642@hr-slim.amd.com> 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> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20150520091213.GA3645@pd.tnic> User-Agent: Mutt/1.5.21 (2010-09-15) X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BN1AFFO11FD032;1:BWeMYkNUe47pl+2JEA3Tz300JzTPiMj5NoEBvTzlBSyNWZgyUs6W32sMLy9I5x+Jg1FuPaWPgK7M9TdmZfWh+eiPgJbSukr9dx2nB5T1PKFkdpbVKhaPMHoXSYCEnaroxchvHLGPGhyYHt1/w/1WaD2tRQXPj3aj6hZOjP7mLggN2OYIHeolDDGIWPFp9/X6nDQXPX+iUPq3adiMepl9UL5lipIVjCykTViTS7oDsarUYqu3DnvM0RKRBt46M9s/PFImkZ719s3GLwVXbtcbBd8H7m2VGZ02dO0dI57NQ/cDGo13tfrEeCtTeTZ7S/wQih9ZVyDf/UzvEZ2yZGMIkg== X-Forefront-Antispam-Report: CIP:165.204.84.222;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(428002)(24454002)(189002)(199003)(164054003)(51704005)(97736004)(105586002)(33656002)(87936001)(5001860100001)(106466001)(4001350100001)(4001540100001)(53416004)(5001830100001)(110136002)(46406003)(64706001)(86362001)(189998001)(83506001)(47776003)(23726002)(92566002)(46102003)(77096005)(97756001)(54356999)(2950100001)(50986999)(50466002)(77156002)(68736005)(101416001)(76176999)(62966003)(93886004)(217873001);DIR:OUT;SFP:1102;SCL:1;SRVR:BN3PR02MB1111;H:atltwp02.amd.com;FPR:;SPF:None;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BN3PR02MB1111; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5005006)(3002001);SRVR:BN3PR02MB1111;BCL:0;PCL:0;RULEID:;SRVR:BN3PR02MB1111; X-Forefront-PRVS: 0583A86C08 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 21 May 2015 14:21:12.5700 (UTC) X-MS-Exchange-CrossTenant-Id: fde4dada-be84-483f-92cc-e026cbee8e96 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=fde4dada-be84-483f-92cc-e026cbee8e96;Ip=[165.204.84.222];Helo=[atltwp02.amd.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR02MB1111 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 20, 2015 at 05:12:13PM +0800, Borislav Petkov wrote: > 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 > OK, I know. Thanks to reminder. :) Thanks, Rui