Re: [RFC][PATCH 0/9] sched: Power scheduler design proposal

[Peter Zijlstra]

On Mon, Jul 15, 2013 at 11:06:50PM +0200, Peter Zijlstra wrote:
> OK, but isn't that part of why the micro controller might not make you go
> faster even if you do program a higher P state?
> 
> But yes, I understand this issue in the 'traditional' cpufreq sense. There's no
> point in ramping the speed if all you do is stall more.
> 
> But I was under the impression the 'hardware' was doing this. If not then we
> need the whole go-faster and go-slower thing and places to call them and means
> to determine to call them etc.


So with the scheduler measuring cpu utilization we could say to go-faster when
u>0.8 and go-slower when u<0.75 or so. Lacking any better metrics like the
stall stuff etc.

So I understand that ondemand spends quite a lot of time 'sampling' what the
system does while the scheduler mostly already knows this. It also has problems
because of the whole sampling thing, either it samples too often and becomes
too expensive/disruptive or it samples too little and misses world+dog.

I was hoping we could do better.


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