linux-kernel - Re: [PATCH 3/4] sched/fair: Check for blocked task after time check

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: <c7d57d3d-1e1f-46a2-805d-e071f5f67960@linux.ibm.com>
Date: Tue, 2 Dec 2025 12:25:52 +0530
From: Shrikanth Hegde <sshegde@...ux.ibm.com>
To: Ingo Molnar <mingo@...nel.org>
Cc: peterz@...radead.org, vincent.guittot@...aro.org,
        linux-kernel@...r.kernel.org, kprateek.nayak@....com,
        dietmar.eggemann@....com, vschneid@...hat.com, rostedt@...dmis.org,
        tglx@...utronix.de, tim.c.chen@...ux.intel.com
Subject: Re: [PATCH 3/4] sched/fair: Check for blocked task after time check



On 12/2/25 11:56 AM, Ingo Molnar wrote:
> 
> * Shrikanth Hegde <sshegde@...ux.ibm.com> wrote:
> 
>> nohz.has_blocked can be updated often as and when CPUs enter idle state.
>> But stats are updated only at regular intervals. Usually fixed to
>> LOAD_AVG_PERIOD=32.
>>
>> Read the value only after time check is successful to avoid cache
>> references to it.
>>
>> Signed-off-by: Shrikanth Hegde <sshegde@...ux.ibm.com>
>> ---
>>   kernel/sched/fair.c | 4 ++--
>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
>> index 55746274af06..5534822fd754 100644
>> --- a/kernel/sched/fair.c
>> +++ b/kernel/sched/fair.c
>> @@ -12440,8 +12440,8 @@ static void nohz_balancer_kick(struct rq *rq)
>>   	 */
>>   	nohz_balance_exit_idle(rq);
>>   
>> -	if (READ_ONCE(nohz.has_blocked) &&
>> -	    time_after(now, READ_ONCE(nohz.next_blocked)))
>> +	if (time_after(now, READ_ONCE(nohz.next_blocked)) &&
>> +	    READ_ONCE(nohz.has_blocked))
>>   		flags = NOHZ_STATS_KICK;
> 
> So this patch makes no sense, as the two fields [1] and
> [2] are almost next to each other:
> 
>    static struct {
>          cpumask_var_t idle_cpus_mask;                                                                           // 0
>          atomic_t nr_cpus;                                                                                       // 8
>          int has_blocked;                /* Idle CPUS has blocked load */                  <========== [1]       // 12
>          int needs_update;               /* Newly idle CPUs need their next_balance collated */                  // 16
>          unsigned long next_balance;     /* in jiffy units */                                                    // 24
>          unsigned long next_blocked;     /* Next update of blocked load in jiffies */      <========== [2]       // 32
>    } nohz ____cacheline_aligned;
> 
> ... and thus they very likely share the same cacheline
> and there can be no reduction in cacheline bouncing
> from this change.
> 
> In fact with OFFSTACK=y the cpumask_var_t is 8 bytes
> and thus the offset of the two fields will be 12 and 32
> within the same 64-byte cacheline, guaranteed. I've
> marked the field offsets in the rightmost column for
> this case.
> 
> Thanks,
> 
> 	Ingo

Ok. Since we fetch the line in either of the case,
read should be minimal overhead. at best we maybe saving one
read. Likely not worth it.

I got a bit carried away. We can ignore this change.