`>> 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 betoo 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 canget done. (where 'work' is obviously still vague, but the softwarerunning 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 optimalor correct value to use (as you said, the "top" type load average is notavailable, which would have been much nicer).`