linux-kernel - Re: [PATCH 1/2] sched/sugov: Ignore 'busy' filter when rq is capped by uclamp

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: <20211220104803.lejehpl44p3b4gvg@e107158-lin.cambridge.arm.com>
Date:   Mon, 20 Dec 2021 10:48:03 +0000
From:   Qais Yousef <qais.yousef@....com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
Cc:     Viresh Kumar <viresh.kumar@...aro.org>,
        "Peter Zijlstra (Intel)" <peterz@...radead.org>,
        Ingo Molnar <mingo@...nel.org>,
        Dietmar Eggemann <dietmar.eggemann@....com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Beata Michalska <Beata.Michalska@....com>,
        Ionela Voinescu <ionela.voinescu@....com>,
        Linux PM <linux-pm@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/2] sched/sugov: Ignore 'busy' filter when rq is capped
 by uclamp_max

On 12/17/21 16:54, Rafael J. Wysocki wrote:
> On Thu, Dec 16, 2021 at 11:53 PM Qais Yousef <qais.yousef@....com> wrote:
> >
> > sugov_update_single_{freq, perf}() contains a 'busy' filter that ensures
> > we don't bring the frqeuency down if there's no idle time (CPU is busy).
> >
> > The problem is that with uclamp_max we will have scenarios where a busy
> > task is capped to run at a lower frequency and this filter prevents
> > applying the capping when this task starts running.
> >
> > We handle this by skipping the filter when uclamp is enabled and the rq
> > is being capped by uclamp_max.
> >
> > We introduce a new function uclamp_rq_is_capped() to help detecting when
> > this capping is taking effect. Some code shuffling was required to allow
> > using cpu_util_{cfs, rt}() in this new function.
> >
> > On 2 Core SMT2 Intel laptop I see:
> >
> > Without this patch:
> >
> >         uclampset -M 0 sysbench --test=cpu --threads = 4 run
> >
> > produces a score of ~3200 consistently. Which is the highest possible.
> >
> > Compiling the kernel also results in frequency running at max 3.1GHz all
> > the time - running uclampset -M 400 to cap it has no effect without this
> > patch.
> >
> > With this patch:
> >
> >         uclampset -M 0 sysbench --test=cpu --threads = 4 run
> >
> > produces a score of ~1100 with some outliers in ~1700. Uclamp max
> > aggregates the performance requirements, so having high values sometimes
> > is expected if some other task happens to require that frequency starts
> > running at the same time.
> >
> > When compiling the kernel with uclampset -M 400 I can see the
> > frequencies mostly in the ~2GHz region. Helpful to conserve power and
> > prevent heating when not plugged in.
> >
> > Fixes: 982d9cdc22c9 ("sched/cpufreq, sched/uclamp: Add clamps for FAIR and RT tasks")
> > Signed-off-by: Qais Yousef <qais.yousef@....com>
> > ---
> >
> > I haven't dug much into the busy filter, but I assume it is something that is
> > still required right?
> 
> It is AFAICS.
> 
> > If there's a better alternative we can take to make this
> > filter better instead, I'm happy to hear ideas. Otherwise hopefully this
> > proposal is logical too.
> 
> It looks reasonable to me.
> 
> For the schedutil changes:
> 
> Acked-by: Rafael J. Wysocki <rafael.j.wysocki@...el.com>

Thanks for having a look!

Cheers

--
Qais Yousef