Re: [PATCH] cpuidle: menu: use nr_running instead of cpuload for calculating perf mult

[Arjan van de Ven <arjan@linux.intel.com>]

>> what the logic is trying to do, on a 10 km level, is to limit the damage
>> of accumulated C state exit time.
>> (I'll avoid the word "latency" here, since the real time people will
>> then immediately think this is about controlling latency response, which
>> it isn't)
> 
> But why? There's a natural limit to his, say the wakeup costs 0.2ms then
> you can only do 5k of those a second. Once you need to actually do some
> work as well this comes down.

but if you only do 100 per second, you still burn 20 msec, which can be
too much if you're performance sensitive.


> But its all idle time, you cannot be idle longer than there is a lack of
> work. So if you're idle too long (because of long exit latency) your
> work shifts and the future idle time reduces, eventually causing a lower
> C state to be used.
> 
> Also, when you notice you're waking up too soon, you can quickly ramp
> down on the C state levels.

when wakeups happen too soon, this already happens.
but that's orthogonal to some degree unfortunately.

> 
>> Now, if you're very idle for a sustained duration (e.g. low load),
>> you're assumed not sensitive to a bit of performance cost.
>> but if you're actually busy (over a longer period, not just "right
>> now"), you're assumed to be sensitive to the performance cost,
>> and what the algorithm does is make it less easy to go into the
>> expensive states.
> 
> My brain still sparks and fizzles when I read that.. it just doesn't
> compute.
> 
> What performance? performance isn't a well defined word.

for the sake of argument, lets call it the amount of work the system can
get done. (where 'work' is obviously still vague, but the software
running on the system will know what it is).

can you afford to do no work for those 20 msec every second ?
the answer to that will be "it depends", and estimating that "depends"
is what the load average value is used for.

I will totally accept that the value used right now is not the optimal
or correct value to use (as you said, the "top" type load average is not
available, which would have been much nicer).