On Mon, Nov 21, 2016 at 04:18:00PM +0530, Viresh Kumar wrote:
On 21-11-16, 11:19, Peter Zijlstra wrote:
Urgh...
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.
Also, there was the idea of; once the above ideas have all been explored; tying the freq ram rate to the power curve.
So NAK on everything tunable here.
Okay, as I told you on IRC, we already have a tunable: rate_limit_us for the schedutil governor which defines the minimum time before which the governor wouldn't try to update the frequency again. Perhaps 10-20 ms is the ideal value for that everyone is using.
So eventually that should also die and we should get inputs from PELT stuff ?
I think it should be replaced by a value provided by the driver. It makes sense to have a rate-limit in so far as that it doesn't make sense to try and program the hardware faster than it can actually change frequencies and/or have a programming cost amortization. And this very clearly is a driver specific thing.
It however doesn't make sense to me to fudge with this in order to achieve ramp up/down differences.