From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ross Lagerwall Subject: Re: [PATCH v3 1/3] x86: Allow limiting the max C-state sub-state Date: Wed, 23 Jul 2014 13:56:45 +0100 Message-ID: <53CFB10D.7050800@citrix.com> References: <1403521791-28859-1-git-send-email-ross.lagerwall@citrix.com> <1403521791-28859-2-git-send-email-ross.lagerwall@citrix.com> <53AADEC4020000780001D362@mail.emea.novell.com> <53AAF023.7040108@citrix.com> <53AC3E76020000780001DB42@mail.emea.novell.com> <53BAB93D.7030805@citrix.com> <53CF819C0200007800024F3A@mail.emea.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; Format="flowed" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <53CF819C0200007800024F3A@mail.emea.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: Liu Jinsong , Xen-devel List-Id: xen-devel@lists.xenproject.org On 07/23/2014 08:34 AM, Jan Beulich wrote: >>>> On 07.07.14 at 17:14, wrote: >> max_csubstate is implemented in the same way as max_cstate. However, >> given the states in the Bay Trail patch (specifically C6N-BYT and >> C6S-BYT), this is clearly insufficient. >> How do you think max_csubstate should limit the substate? Should it be >> something like a max_csubstate = 2 permits the first and second substates? > > It's not at all clear to me how to properly translate the CPU internal > state identifiers to/from command line option values, in a forward > compatible manner. > Well, given that Xen treats the cpuidle_state array as a linear sequence of states, and they are ordered by exit latency/target residency, one approach is to have the command-line parameters control how deep down into the state array the processor is allowed to travel, as was my first approach. I know you rejected this before because it was hardware-specific and broke the notion of a C-state but I still feel it's the simplest solution given that any other way of mapping to CPU internal states is likely to be more complex and even more hardware dependent... Regards -- Ross Lagerwall