Re: [RFC PATCH RESEND 01/10] sched/fair: Do not set_rd_overloaded() if rd->online != env->cpus

[Xin Zhao]

On Thu, 10 Sep 2026 14:00:43 +0530 K Prateek Nayak <kprateek.nayak@xxxxxxx> wrote:

> Only two cases manipulate env.cpus:
> 
> 1. LBF_DST_PINNED: The CPU doing the load balancing clears itself from
>    env.cpus since pinned tasks cannot be moved to it and goes to
>    "more_balance" but "more_balance" does not recompute stats and never
>    reaches update_sd_lb_stats().
> 
> 2. LBF_ALL_PINNED: CPU with no movable task is cleared from env.cpus.
>    How will rd->overload being set for a CPU that cannot be helped make
>    newidle balance any more efficient?

The effective range of LBF_ALL_PINNED is specific to a particular src CPU
and a particular dst CPU, whereas rd->overload is indeed a global marker
that affects all CPUs with idle states. Regardless of whether case 1 has
been processed, it seems unreasonable to me that rd->overload could be
incorrectly cleared due to case 2, because the scopes of the LBF_ALL_PINNED
and ->overload flags are not equivalent.


>  Since LBF_ALL_PINNED is known with busiest's rq_lock held, maybe you
>  can set a rq->flag and later consume it in add_nr_running() to
>  do set_rd_overloaded() selectively.

If the global rd->overload is incorrectly cleared due to LBF_ALL_PINNED
from src (CPUA) to dst (CPUB), it is possible that CPUB may experience
no changes in nr_running for a certain period of time. Therefore, I think
modifying it in add_nr_running may not be appropriate. I'm not sure if my
understanding is correct.


--
Xin Zhao