On Mon, Apr 10, 2017 at 12:38 PM, Brendan Jackman <brendan.jack...@arm.com> wrote: > Hi Rafael, > > On Mon, Apr 10 2017 at 00:10, Rafael J. Wysocki wrote: >> From: Rafael J. Wysocki <rafael.j.wyso...@intel.com> >> >> Make the schedutil governor compute the initial (default) value of >> the rate_limit_us sysfs attribute by multiplying the transition >> latency by a multiplier depending on the policy and set by the >> scaling driver (instead of using a constant for this purpose). >> >> That will allow scaling drivers to make schedutil use smaller default >> values of rate_limit_us and reduce the default average time interval >> between consecutive frequency changes. >> > > I've been thinking about this over the last couple of days, and I'm > thinking (in opposition to what I said at OSPM Pisa) that allowing > drivers to specify a _multiplier_ isn't ideal, since you lose > granularity when you want your rate limit to be close to your transition > latency (i.e. if your multiplier would be 2.5 or something). > > Can we instead just have an independent field > policy->default_rate_limit_us or similar?
Yes, we can. Let me cut a v2 of this, shouldn't be too hard. :-) Thanks, Rafael