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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <CABk29Ntuzux+AYEhuDO0EPKEupAEsQ+=OwfSi8VrtUmUXZbHEQ@mail.gmail.com>
Date: Wed, 12 Mar 2025 12:24:11 -0700
From: Josh Don <joshdon@...gle.com>
To: Abel Wu <wuyun.abel@...edance.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 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).

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>