linux-kernel - Re: Re: [RFC PATCH 2/2] sched/fair: Do not specialcase SCHED

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <fffe9509-6260-43e9-95e6-f4aa6780bb7a@bytedance.com>
Date: Thu, 13 Mar 2025 15:41:57 +0800
From: Abel Wu <wuyun.abel@...edance.com>
To: Josh Don <joshdon@...gle.com>
Cc: K Prateek Nayak <kprateek.nayak@....com>, Ingo Molnar <mingo@...hat.com>,
 Peter Zijlstra <peterz@...radead.org>, Juri Lelli <juri.lelli@...hat.com>,
 Vincent Guittot <vincent.guittot@...aro.org>,
 Dietmar Eggemann <dietmar.eggemann@....com>,
 Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>,
 Mel Gorman <mgorman@...e.de>, Valentin Schneider <vschneid@...hat.com>,
 Tianchen Ding <dtcccc@...ux.alibaba.com>,
 "open list:SCHEDULER" <linux-kernel@...r.kernel.org>,
 Viresh Kumar <viresh.kumar@...aro.org>
Subject: Re: Re: [RFC PATCH 2/2] sched/fair: Do not specialcase SCHED_IDLE
 cpus in select slowpath

On 3/13/25 3:24 AM, Josh Don wrote:
> On Tue, Mar 11, 2025 at 9:43 AM Abel Wu <wuyun.abel@...edance.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@...gle.com>

Thanks!