[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZfAuKjZ7pNgE2pc7@gmail.com>
Date: Tue, 12 Mar 2024 11:27:54 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Shrikanth Hegde <sshegde@...ux.ibm.com>
Cc: Dietmar Eggemann <dietmar.eggemann@....com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Peter Zijlstra <peterz@...radead.org>,
Valentin Schneider <vschneid@...hat.com>,
Vincent Guittot <vincent.guittot@...aro.org>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 05/13] sched/balancing: Rename load_balance() =>
sched_balance_rq()
* Shrikanth Hegde <sshegde@...ux.ibm.com> wrote:
>
>
> On 3/8/24 4:48 PM, Ingo Molnar wrote:
> > Standardize scheduler load-balancing function names on the
> > sched_balance_() prefix.
> >
> > Also load_balance() has become somewhat of a misnomer: historically
> > it was the first and primary load-balancing function that was called,
> > but with the introduction of sched domains, it's become a lower
> > layer function that balances runqueues.
> >
> > Rename it to sched_balance_rq() accordingly.
>
> nit: Can this be sched_balance_rqs()? since load balancing happens
> between two runqeueus.
Yeah, but we really are primarily balancing *this* runqueue - because it
got potentially out of balance due to a newidle event, or we are checking
its balance in the periodic load-balancing tick. So it's really a shortcut
for 'balance this runqueue' - singular, although internally it will indeed
search for a source runqueue to move tasks from.
So it's a kind of a pull-balancing model, with a singular target (this_cpu).
> > Signed-off-by: Ingo Molnar <mingo@...nel.org>
> > Cc: Dietmar Eggemann <dietmar.eggemann@....com>
> > Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> > Cc: Peter Zijlstra <peterz@...radead.org>
> > Cc: Shrikanth Hegde <sshegde@...ux.ibm.com>
> > Cc: Valentin Schneider <vschneid@...hat.com>
> > Cc: Vincent Guittot <vincent.guittot@...aro.org>
> > ---
>
> Though one would have been familiar with names(for someone started recently),
> given the correct behaviour and historical context helps why the name changes are making sense.
>
> Reviewed-by: Shrikanth Hegde <sshegde@...ux.ibm.com>
Thanks! I've added your Reviewed-by tags to the series.
Ingo
Powered by blists - more mailing lists