From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753059AbbETLVP (ORCPT ); Wed, 20 May 2015 07:21:15 -0400 Received: from cantor2.suse.de ([195.135.220.15]:37479 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752103AbbETLVO (ORCPT ); Wed, 20 May 2015 07:21:14 -0400 Date: Wed, 20 May 2015 13:21:10 +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: <20150520112110.GG3645@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> <20150520105032.GD3645@pd.tnic> <20150520111120.GA25215@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150520111120.GA25215@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 01:11:20PM +0200, Ingo Molnar wrote: > - MWAITX takes a 'timeout' parameter, but otherwise behaves exactly > like MWAIT: i.e. once idle it won't exit idle on its own Let me quote the commit message: "MWAITT, another name is MWAITX (MWAIT with extensions), has a configurable timer that causes MWAITX to exit on expiration." You need to set the second bit in ECX to enable the timer. I guess if you don't, then you get normal MWAIT but then you don't need the timeout either... > - based on the 'timeout' hint, MWAITX can internally optimize how > deep sleep it enters. If the timeout is large it goes deep, if > it's small, it goes shallow. I haven't heard anything about handling the timeout this way and if it is not done this way, maybe Rui could forward this idea to hw people... > If it's a true timeout, as you suggest, then I don't see any obvious > way to support it, especially if it does not give access to deeper > sleep states. Right. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --