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.
(Note that the decay limit would only be applied on the per-task signal, not the accumulated signal.)
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.
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..
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.