[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...

Regards
--
Ross Lagerwall

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel


 


Rackspace

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