lkml.org 
[lkml]   [2021]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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@arm.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@arm.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@intel.com>

Thanks for having a look!

Cheers

--
Qais Yousef

\
 
 \ /
  Last update: 2021-12-20 11:48    [W:0.048 / U:0.132 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site