Re: [PATCH] sched/cache: Keep nr_pref_llc_running in the runnable domain

[Tim Chen <tim.c.chen@linux.intel.com>]

On Fri, 2026-08-28 at 10:20 +0800, Zhan Xusheng wrote:
> From: Zhan Xusheng <zhanxusheng@xiaomi.com>
> 
> The ordering the skip depends on is not visible in the diff, so for the
> record: dequeue_hierarchy() at fair.c:8148 reaches account_llc_dequeue()
> through dequeue_entity(), and clear_delayed() runs only afterwards at
> 8164, so se->sched_delayed is still set when account_llc_dequeue() tests
> it.
> 
> The sequences balance:
> 
>   enqueue, dequeue                   +1, -1
>   enqueue, sleep, wake, dequeue      +1, -1 set_delayed,
>                                      +1 clear_delayed, -1
>   enqueue, sleep, real dequeue       +1, -1, skip, no re-add
>   load balance moves a delayed task  source unchanged, destination +1
>                                      with sched_delayed already clear
> 
> requeue_delayed_entity() does not reach account_entity_enqueue(), doing
> only __enqueue_entity() and clear_delayed(), so the wake path cannot
> double count.  account_mm_sched() cannot see a delayed task either, since
> task_running_on_cpu() at fair.c:12245 requires task_on_rq_queued() on the
> current cpu and the caller is update_curr().

Thanks for reviewing the patch proposed to fix the problem you pointed out,
and validating that the nr_pref_llc_running accounting under the
various scenarios are sane.

> 
> sd->llc_counts is right to stay on queued semantics: both readers compare
> it against another llc_counts value, at fair.c:11895 and 13228, so delayed
> tasks shift both sides alike.
> 

Yes, sd->llc_counts do not need to change as you pointed out.

> Reviewed-by: Zhan Xusheng <zhanxusheng@xiaomi.com>
> 

Tim