Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1660269

Re: [RFC] sched: fair: Don't update CPU frequency too frequently

Show all headers | View raw

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

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

[RFC] sched: fair: Don't update CPU frequency too frequently Viresh Kumar <viresh.kumar@linaro.org> - 2017-06-01 13:40 +0200
  Re: [RFC] sched: fair: Don't update CPU frequency too frequently Peter Zijlstra <peterz@infradead.org> - 2017-06-01 14:30 +0200
    Re: [RFC] sched: fair: Don't update CPU frequency too frequently Viresh Kumar <viresh.kumar@linaro.org> - 2017-06-07 14:10 +0200
      Re: [RFC] sched: fair: Don't update CPU frequency too frequently Morten Rasmussen <morten.rasmussen@arm.com> - 2017-06-07 17:50 +0200
        Re: [RFC] sched: fair: Don't update CPU frequency too frequently "Rafael J. Wysocki" <rafael@kernel.org> - 2017-06-08 00:00 +0200

csiph-web