linux-kernel - Re: [PATCH] sched/cpufreq_schedutil: use now as reference when aggregating shared policy requests

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170504144042.GC13739@e106622-lin>
Date:   Thu, 4 May 2017 15:40:42 +0100
From:   Juri Lelli <juri.lelli@....com>
To:     "Rafael J. Wysocki" <rjw@...ysocki.net>
Cc:     linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org,
        viresh.kumar@...aro.org, peterz@...radead.org,
        vincent.guittot@...aro.org
Subject: Re: [PATCH] sched/cpufreq_schedutil: use now as reference when
 aggregating shared policy requests

Hi Rafael,

On 04/05/17 16:29, Rafael J. Wysocki wrote:
> On Wednesday, May 03, 2017 02:30:48 PM Juri Lelli wrote:
> > Currently, sugov_next_freq_shared() uses last_freq_update_time as a
> > reference to decide when to start considering CPU contributions as
> > stale.
> > 
> > However, since last_freq_update_time is set by the last CPU that issued
> > a frequency transition, this might cause problems in certain cases. In
> > practice, the detection of stale utilization values fails whenever the
> > CPU with such values was the last to update the policy. For example (and
> > please note again that the SCHED_CPUFREQ_RT flag is not the problem
> > here, but only the detection of after how much time that flag has to be
> > considered stale), suppose a policy with 2 CPUs:
> > 
> >                CPU0                |               CPU1
> >                                    |
> >                                    |     RT task scheduled
> >                                    |     SCHED_CPUFREQ_RT is set
> >                                    |     CPU1->last_update = now
> >                                    |     freq transition to max
> >                                    |     last_freq_update_time = now
> >                                    |
> > 
> >                         more than TICK_NSEC nsecs
> > 
> >                                    |
> >      a small CFS wakes up          |
> >      CPU0->last_update = now1      |
> >      delta_ns(CPU0) < TICK_NSEC*   |
> >      CPU0's util is considered     |
> >      delta_ns(CPU1) =              |
> >       last_freq_update_time -      |
> >       CPU1->last_update = 0        |
> >       < TICK_NSEC                  |
> >      CPU1 is still considered      |
> >      CPU1->SCHED_CPUFREQ_RT is set |
> >      we stay at max (until CPU1    |
> >      exits from idle)              |
> > 
> > * delta_ns is actually negative as now1 > last_freq_update_time
> > 
> > While last_freq_update_time is a sensible reference for rate limiting,
> > it doesn't seem to be useful for working around stale CPU states.
> > 
> > Fix the problem by always considering now (time) as the reference for
> > deciding when CPUs have stale contributions.
> > 
> > Signed-off-by: Juri Lelli <juri.lelli@....com>
> > Cc: Rafael J. Wysocki <rafael.j.wysocki@...el.com>
> > Cc: Viresh Kumar <viresh.kumar@...aro.org>
> 
> OK
> 
> I'll queue this up if there are no objections from the people in the CC.
> 

Thanks!

Best,

- Juri