linux-kernel - Re: [RFC PATCH 5/6] sched/fair: trigger the update of blocked load on newly idle cpu

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: <CAKfTPtANm-b+iKU09Rvu1Tu5MBpNAkmzn0FOstURWs4royTMpQ@mail.gmail.com>
Date:   Tue, 9 Feb 2021 15:22:55 +0100
From:   Vincent Guittot <vincent.guittot@...aro.org>
To:     Dietmar Eggemann <dietmar.eggemann@....com>
Cc:     Ingo Molnar <mingo@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Steven Rostedt <rostedt@...dmis.org>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        Frederic Weisbecker <fweisbec@...il.com>,
        Thomas Gleixner <tglx@...utronix.de>,
        Daniel Bristot de Oliveira <bristot@...hat.com>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Joel Fernandes <joel@...lfernandes.org>,
        Qais Yousef <qais.yousef@....com>
Subject: Re: [RFC PATCH 5/6] sched/fair: trigger the update of blocked load on
 newly idle cpu

On Tue, 9 Feb 2021 at 14:47, Dietmar Eggemann <dietmar.eggemann@....com> wrote:
>
> On 05/02/2021 12:48, Vincent Guittot wrote:
> > Instead of waking up a random and already idle CPU, we can take advantage
> > of this_cpu being about to enter idle to run the ILB and update the
> > blocked load.
> >
> > Signed-off-by: Vincent Guittot <vincent.guittot@...aro.org>
> > ---
> >  include/linux/sched/nohz.h |  2 ++
> >  kernel/sched/fair.c        | 11 ++++++++---
> >  kernel/sched/idle.c        |  6 ++++++
> >  3 files changed, 16 insertions(+), 3 deletions(-)
> >
> > diff --git a/include/linux/sched/nohz.h b/include/linux/sched/nohz.h
> > index 6d67e9a5af6b..74cdc4e87310 100644
> > --- a/include/linux/sched/nohz.h
> > +++ b/include/linux/sched/nohz.h
> > @@ -9,8 +9,10 @@
> >  #if defined(CONFIG_SMP) && defined(CONFIG_NO_HZ_COMMON)
> >  extern void nohz_balance_enter_idle(int cpu);
> >  extern int get_nohz_timer_target(void);
> > +extern void nohz_run_idle_balance(int cpu);
> >  #else
> >  static inline void nohz_balance_enter_idle(int cpu) { }
> > +static inline void nohz_run_idle_balance(int cpu) { }
> >  #endif
>
> (1) Since nohz_run_idle_balance() would be an interface one sched class
> (fair) exports to another (idle) I wonder if kernel/sched/sched.h would
> be the more appropriate include file to export/define it?

Yes probably. I have been influenced by the "nohz" filename but
kernel/sched/sched.h is better

>
> nohz_balance_exit_idle() is exported via kernel/sched/sched.h (used only
> within the scheduler) whereas nohz_balance_enter_idle() is exported via
> include/linux/sched/nohz.h (used in kernel/time/tick-sched.c).
>
> Isn't include/linux/sched/nohz.h the interface between kernel/sched/ and
> kernel/time?
>
> There is one exception already though: calc_load_nohz_remote() defined
> in kernel/sched/loadavg.c and (only) used in kernel/sched/core.c.
>
>
> (2) Is there a need for an extra function nohz_run_idle_balance()?
> do_idle() could call nohz_idle_balance() directly in case in would be
> exported instead.

I didn't want to expose the 2 parameters of nohz_idle_balance in
do_idle() and especially the enum cpu_idle_type but it seems that it
is already available so I can probably call
nohz_idle_balance(cpu_rq(cpu), CPU_IDLE); directly


>
> [...]