Re: Re: [RFC PATCH 2/2] sched/fair: Do not specialcase SCHED_IDLE cpus in select slowpath

[Abel Wu <wuyun.abel@bytedance.com>]

On 3/13/25 3:24 AM, Josh Don wrote:
> On Tue, Mar 11, 2025 at 9:43 AM Abel Wu <wuyun.abel@bytedance.com> wrote:
> [snip]
>> False positives are possible, but the possibility can be reduced by
>> optimizing blooming setup.
> 
> An interesting approach, thanks for sharing. Not that it matters
> (given that we're not pursuing this now), but just to call out that
> this has poor scaling with large cgroup hierarchies and updates to
> cgroup idle state, so in an actual implementation it would be ideal to
> do the updates asynchronously from sched_group_set_idle (ie. via a
> kworker).

Good idea. Async update makes sense since sched_idle_cpu() is not
required 100% correct, and with this we also can join several updates
into one.

> 
> We could also greatly simplify this down if we assume certain
> contrived setups, for example if we assume we primarily care about
> sched_idle cpu preemption against only root-level sched_idle cgroups
> (as everything inside a root-level sched_idle cgroup is trivially
> preemptible by a task from another hierarchy). But obviously your
> cgroup setup doesn't fall under this category, so it is not very
> useful.
> 
>> I chose the simplest way for now to workaround the issue we encountered,
>> while I am still trying to do something to get rid of sched_idle_cpu().
>> Thoughts?
> 
> That sounds reasonable to me.
> 
> Reviewed-by: Josh Don <joshdon@google.com>

Thanks!