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

[Peter Zijlstra]

On Mon, 2012-06-04 at 10:25 -0700, Arjan van de Ven wrote:
> 
> 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).

Screw the software, explain it to me.

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

See this just doesn't make any sense..

If there's work, we're not idle. If there's more work we're idle less.
We're just not going to be idle 20 msec every second if there's more to
do.

And like I said many times now, if you inflate some of the idle periods,
the work shifts (it doesn't become less) and a next idle period will be
smaller -- since we'll only become idle again once all work is done.

( and since its smaller you decrease your idle guestimate, and lower you
C state level )

The absolute only thing any of this makes any difference to is
synchronous stuff, like round-trip latencies. If you have a workload
that doesn't do anything until something else happens and so on. Then,
if you delay each signal a bit the total time will increase and the
amount of stuff done in a given time decreases.

However, if you stuff enough work down that pipe, the total throughput
should still be good -- esp. if you can saturate the thing and all idle
time goes away.

You said that accrued latency per time unit was an approximate measure,
but afaict that's related to what you want, whereas the unix
load-average is completely unrelated to any of this.

Anyway, as it stands you're better off ripping the entire thing out,
since I don't see how it could have worked, given that you're using an
entirely random measure of something.

Also, I'm still not understanding why decreasing your idle-period
guestimation when you're woken up early isn't catching any of this.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/