From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754130AbbFJCpD (ORCPT ); Tue, 9 Jun 2015 22:45:03 -0400 Received: from mail-bn1on0138.outbound.protection.outlook.com ([157.56.110.138]:39090 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753877AbbFJCoz (ORCPT ); Tue, 9 Jun 2015 22:44:55 -0400 Authentication-Results: spf=none (sender IP is 165.204.84.222) smtp.mailfrom=amd.com; amacapital.net; dkim=none (message not signed) header.d=none; X-WSS-ID: 0NPPJMM-08-CR9-02 X-M-MSG: Date: Wed, 10 Jun 2015 10:40:51 +0800 From: Huang Rui To: Borislav Petkov , Andy Lutomirski CC: "Xue, Ken" , Thomas Gleixner , "Li, Tony" , "x86@kernel.org" , John Stultz , Aaron Lu , "Rafael J. Wysocki" , =?iso-8859-1?Q?Fr=E9d=E9ric?= Weisbecker , "Suthikulpanit, Suravee" , Fengguang Wu , "Len Brown" , "linux-kernel@vger.kernel.org" , Peter Zijlstra Subject: Re: [PATCH v2 1/4] x86, mwaitt: add monitorx and mwaitx instruction Message-ID: <20150610024051.GC17509@hr-slim.amd.com> References: <1433819621-15093-1-git-send-email-ray.huang@amd.com> <1433819621-15093-2-git-send-email-ray.huang@amd.com> <20150609082306.GN3644@twins.programming.kicks-ass.net> <20150609094856.GA17030@hr-slim.amd.com> <20150609100501.GD22105@pd.tnic> <20150609170613.GI22105@pd.tnic> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: <20150609170613.GI22105@pd.tnic> User-Agent: Mutt/1.5.21 (2010-09-15) X-EOPAttributedMessage: 0 X-Microsoft-Exchange-Diagnostics: 1;BN1AFFO11FD031;1:aEzx3NTqxlbzkDR+NF3AIY3VJwYXu3sV30ZYngtYt96CIeJG5DRWfWKZKd53sz+nC3ZOE5/42wvPWR0Z1DUGTz9GksRDZg87HZPoRbULJq9ruKnZNrugsCK7LI3NvujPaBfn6gYzGPyjDjjAXT+2zfEmpb7LYi8QMFQslNcf5ejV91ZkOhyLMQO1i5DEhIYNPFmM8mC4D730FpKCKwRoCf/O5TwfsUsxt1YBrT8UVhRCE8JCt/bhZtlvv02gVV7uqOZZLSDGRN3T06i5n1GL9kBxGO6oRwV1OEd4z1P7ilM9LrDP4SIuwALNbJJ8tB0sKpdEEpBmf0eIK/8RJUXDmA== X-Forefront-Antispam-Report: CIP:165.204.84.222;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10019020)(6009001)(428002)(199003)(51704005)(189002)(24454002)(164054003)(101416001)(76176999)(97756001)(5001770100001)(54356999)(189998001)(77096005)(46102003)(92566002)(33656002)(5003600100001)(50466002)(2950100001)(77156002)(50986999)(46406003)(93886004)(47776003)(87936001)(105586002)(106466001)(86362001)(23726002)(53416004);DIR:OUT;SFP:1102;SCL:1;SRVR:BY1PR02MB1113;H:atltwp02.amd.com;FPR:;SPF:None;MLV:sfv;A:1;MX:1;LANG:en; X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY1PR02MB1113; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(5005006)(520003)(3002001);SRVR:BY1PR02MB1113;BCL:0;PCL:0;RULEID:;SRVR:BY1PR02MB1113; X-Forefront-PRVS: 06036BD506 X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 10 Jun 2015 02:44:51.5124 (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: BY1PR02MB1113 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 09, 2015 at 07:06:14PM +0200, Borislav Petkov wrote: > On Tue, Jun 09, 2015 at 09:44:59AM -0700, Andy Lutomirski wrote: > > [1] For those who weren't bitten by this repeatedly, modern Intel CPUs > > (at least Sandy Bridge, anyway) will, by default, detect when all > > cores are in C1 or deeper, think to themselves "wow, the OS selected > > C1 -- it must want a very deep sleep indeed", and put the whole > > package into some kind of deep sleep state. The subsequent wakeup > > takes tens of milliseconds. Doing this in udelay would be awful. > > That's a good point. Reportedly, the current MWAITX enters something > between C0 and C1 but the way I understood it, going forward, it will > enter deeper sleep states. > > So for shallow C-states, your idle enter/exit latency is low enough but > I'd guess deeper states would be a problem. > Andy, Boris, that's right. Thanks. :) If MWAITX will enter C1 and restore back repeatedly. It will impact the accuracy of delay. I will ask HW designer to check if it already has configuration to control the target power state. Thanks, Rui