On 8/15/2014 7:24 AM, Ashwin Chaugule wrote:
we've found that so far that there are two reasonable options
Let the OS device (old style)
Let the hardware decide (new style)
is there in practice today in the turbo range (which is increasingly
the whole thing) and the hardware can make decisions about power budgetting on a timescale the OS can never even dream of, so once you give control the the hardware (with CPPC or native) it's normally better to just get out of the way as OS.
Interesting. This sounds like X86 plans to use the Autonomous bits that got added to the CPPC spec. (v5.1)?
if and when x86/Intel implement that, we will certainly evaluate it to see how it behaves... but based on todays use of the hw control of the actual p-state... I would expect that evaluation to pass.
note that on todays multi-core x96 systems, in practice you operate mostly in the turbo range (I am ignoring mostly-idle workloads since there the p-state isn't nearly as relevant anyway); all it takes for one of the cores to request a turbo-range state, and the whole chip operates in turbo mode.. and in turbo mode the hardware already picks the frequency/voltage.
with the current (and more so, past) Linux behavior, even at moderate loads you end up there; the more cores you have the more true that becomes.
I agree that the platform can make decisions on a much finer timescale. But even in the non-Autonomous mode, by providing the bounds around a Desired Value, the OS can get out of the way knowing that the platform would deliver something in the range it requested. If the OS can provide bounds, it seems to me that the platform can make more optimum decisions, rather than trying to guess whats running (or not).
I highly question that the OS can provide intelligent bounds.
When are you going to request an upper bound that is lower than maximum? (don't say thermals, there are other mechanisms for controlling thermals that work much better than direct P state control). Are you still going to do that even if sometimes lower frequencies end up costing more battery? (race-to-halt and all that)
I can see cases where you bump the minimum for QoS reasons, but even there I would dare to say that at best the OS will be doing wild-ass guesses.