Messages in this thread | | | From | "Rafael J. Wysocki" <> | Date | Wed, 7 Jun 2017 23:55:12 +0200 | Subject | Re: [RFC] sched: fair: Don't update CPU frequency too frequently |
| |
On Wed, Jun 7, 2017 at 5:43 PM, Morten Rasmussen <morten.rasmussen@arm.com> wrote: > On Wed, Jun 07, 2017 at 05:36:55PM +0530, Viresh Kumar wrote: >> + Patrick, >> >> On 01-06-17, 14:22, Peter Zijlstra wrote: >> > On Thu, Jun 01, 2017 at 05:04:27PM +0530, Viresh Kumar wrote: >> > > This patch relocates the call to utilization hook from >> > > update_cfs_rq_load_avg() to task_tick_fair(). >> > >> > That's not right. Consider hardware where 'setting' the DVFS is a >> > 'cheap' MSR write, doing that once every 10ms (HZ=100) is absurd. >> >> Yeah, that may be too much for such a platforms. Actually we (/me & Vincent) >> were worried about the current location of the utilization update hooks and >> believed that they are getting called way too often. But yeah, this patch >> optimized it way too much. >> >> One of the goals of this patch was to avoid doing small OPP updates from >> update_load_avg() which can potentially block significant utilization changes >> (and hence big OPP changes) while a task is attached or detached, etc. > > To me that sounds like you want to apply a more clever filter to the > utilization updates than a simple rate limiter as Peter suggests below. > IMHO, it would be better to feed schedutil with all the available > information and improve the filtering policy there instead of trying to > hack the policy tweaking the input data.
Agreed.
Unless the tweaked input data would be used somewhere else too, that is.
>> > We spoke about this problem in Pisa, the proposed solution was having >> > each driver provide a cost metric and the generic code doing a max >> > filter over the window constructed from that cost metric. > > Maybe it is possible to somehow let the rate at which we allow OPP > changes depend on the size of the 'error' delta between the current OPP > and what we need. So radical changes causes OPP changes immediately, and > small corrections have to wait longer?
That sounds reasonable to me.
Thanks, Rafael
| |