On 21/11/16 13:26, Peter Zijlstra wrote:
On Mon, Nov 21, 2016 at 12:14:32PM +0000, Juri Lelli wrote:
On 21/11/16 11:19, Peter Zijlstra wrote:
So no tunables and rate limits here at all please.
During LPC we discussed the rampup and decay issues and decided that we should very much first address them by playing with the PELT stuff. Morton was going to play with capping the decay on the util signal. This should greatly improve the ramp-up scenario and cure some other wobbles.
The decay can be set by changing the over-all pelt decay, if so desired.
Do you mean we might want to change the decay (make it different from ramp-up) once for all, or maybe we make it tunable so that we can address different power/perf requirements?
So the limited decay would be the dominant factor in ramp-up time, leaving the regular PELT period the dominant factor for ramp-down.
Hmmm, AFAIU the limited decay will help not forgetting completely the contribution of tasks that sleep for a long time, but it won't modify the actual ramp-up of the signal. So, for new tasks we will need to play with a sensible initial value (trading off perf and power as usual).
(Note that the decay limit would only be applied on the per-task signal, not the accumulated signal.)
Right, and since schedutil consumes the latter, we could still suffer from too frequent frequency switch events I guess (this is where the down threshold thing came as a quick and dirty fix). Maybe we can think of some smoothing applied to the accumulated signal, or make it decay slower (don't really know what this means in practice, though :) ?
It could be an option, for some, to build the kernel with a PELT window of 16ms or so (half its current size), this of course means regenerating all the constants etc.. And this very much is a compile time thing.
Right. I seem to remember that helped a bit for mobile type of workloads. But never did a thorough evaluation.
We could fairly easy; if this is so desired; make the PELT window size a CONFIG option (hidden by default).
But like everything; patches should come with numbers justifying them etc..
Sure. :)
Also, there was the idea of; once the above ideas have all been explored; tying the freq ram rate to the power curve.
Yep. That's an interesting one to look at, but it might require some time.
Sure, just saying that we should resist knobs until all other avenues have been explored. Never start with a knob.