[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <daa3f8c5-47d4-4472-9c35-b7709643f1bd@linux.ibm.com>
Date: Tue, 6 Jan 2026 12:14:05 +0530
From: Shrikanth Hegde <sshegde@...ux.ibm.com>
To: K Prateek Nayak <kprateek.nayak@....com>
Cc: linux-kernel@...r.kernel.org, juri.lelli@...hat.com, vschneid@...hat.com,
tglx@...utronix.de, dietmar.eggemann@....com, anna-maria@...utronix.de,
frederic@...nel.org, wangyang.guo@...el.com, mingo@...nel.org,
peterz@...radead.org, vincent.guittot@...aro.org
Subject: Re: [PATCH v2 2/3] sched/fair: Change likelyhood of nohz.nr_cpus and
do stats update if its due
On 1/6/26 11:20 AM, K Prateek Nayak wrote:
> Hello Shrikanth,
>
> On 1/6/2026 9:53 AM, Shrikanth Hegde wrote:
>>> There are also nuances like the smp_mb__after_atomic() in
>>
>> That reminds me, need to upgrade this to smp_mb now, given atomic is gone.
>
> Isn't cpumask_set_cpu() also an atomic op?
>
> set_bit() has a comment stating it is a "relaxed atomic operation" in
> asm-generic/bitops/instrumented-atomic.h which makes it similar to a
> atomic_inc().
"
* set_bit - Atomically set a bit in memory
* @nr: the bit to set
* @addr: the address to start counting from
*
* This is a relaxed atomic operation (no implied memory barriers).
"
I believed the comment. If it was relaxed atomic operation then
one would need a smp barrier.
But it calls arch_set_bit.
Looking at x86 implementation in arch/x86/include/asm/bitops.h it
looks like it does full smp_mb. Whereas on powerpc it doesn't.
So smp_mb__after_atomic can remain as is.
Effective change to v3 is return instead of out.
Powered by blists - more mailing lists