[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZeWTZMnX8uLwzjui@gmail.com>
Date: Mon, 4 Mar 2024 10:24:52 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Shrikanth Hegde <sshegde@...ux.ibm.com>
Cc: Peter Zijlstra <peterz@...radead.org>,
Vincent Guittot <vincent.guittot@...aro.org>,
Dietmar Eggemann <dietmar.eggemann@....com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Valentin Schneider <vschneid@...hat.com>,
Nicholas Piggin <npiggin@...il.com>,
LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/7] sched/balancing: Switch the
'DEFINE_SPINLOCK(balancing)' spinlock into an 'atomic_t
sched_balance_running' flag
* Shrikanth Hegde <sshegde@...ux.ibm.com> wrote:
>
>
> On 3/1/24 4:39 PM, Ingo Molnar wrote:
> > The 'balancing' spinlock added in:
>
> Hi Ingo.
>
> >
> > 08c183f31bdb ("[PATCH] sched: add option to serialize load balancing")
> >
>
>
> [...]
>
> >
> > need_serialize = sd->flags & SD_SERIALIZE;
> > if (need_serialize) {
> > - if (!spin_trylock(&balancing))
> > + if (atomic_cmpxchg_acquire(&sched_balance_running, 0, 1))
>
> Thinking from very little I know, I may be completely wrong.
>
> Is it possible that arch_spin_trylock, which would be called from spin_trylock is
> faster in some architectures? Maybe in contended case?
This code path should never really be 'contended': SD_SERIALIZE is only set
for the outermost, largest domains (NUMA and up) that get balanced
infrequently. This change is more for the sake of readability: a flag
disguised as a spinlock.
Thanks,
Ingo
Powered by blists - more mailing lists