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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJZ5v0h9=Fx2TvgW2=f4RLr+Dh0rMUxt-m6yp2bcd6F_WeHwCA@mail.gmail.com>
Date:   Wed, 7 Jun 2017 23:55:12 +0200
From:   "Rafael J. Wysocki" <rafael@...nel.org>
To:     Morten Rasmussen <morten.rasmussen@....com>
Cc:     Viresh Kumar <viresh.kumar@...aro.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Ingo Molnar <mingo@...hat.com>,
        Rafael Wysocki <rjw@...ysocki.net>,
        Lists linaro-kernel <linaro-kernel@...ts.linaro.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Linux PM <linux-pm@...r.kernel.org>,
        Juri Lelli <Juri.Lelli@....com>,
        Dietmar Eggemann <Dietmar.Eggemann@....com>,
        Patrick Bellasi <patrick.bellasi@....com>
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@....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