[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v3 1/3] x86: Allow limiting the max C-state sub-state

On 07/23/2014 08:34 AM, Jan Beulich wrote:
On 07.07.14 at 17:14, <ross.lagerwall@xxxxxxxxxx> 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...

Ross Lagerwall

Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.