On Mon, Nov 21, 2016 at 04:18:00PM +0530, Viresh Kumar wrote:

On 21-11-16, 11:19, Peter Zijlstra wrote:

quoted

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.