linux-kernel - Re: [PATCH] sched/core: Report failed rt migrations to non-root cgroup without rt bandwidth under RT_GROUP

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: <20250916170735.GA5293@pauld.westford.csb>
Date: Tue, 16 Sep 2025 13:07:35 -0400
From: Phil Auld <pauld@...hat.com>
To: Aaron Tomlin <atomlin@...mlin.com>
Cc: Michal Koutný <mkoutny@...e.com>, mingo@...hat.com,
	peterz@...radead.org, juri.lelli@...hat.com,
	vincent.guittot@...aro.org, dietmar.eggemann@....com,
	rostedt@...dmis.org, bsegall@...gle.com, mgorman@...e.de,
	vschneid@...hat.com, shashank.mahadasyam@...y.com,
	longman@...hat.com, tj@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] sched/core: Report failed rt migrations to non-root
 cgroup without rt bandwidth under RT_GROUP_SCHED

On Tue, Sep 16, 2025 at 12:57:04PM -0400 Aaron Tomlin wrote:
> On Tue, Sep 16, 2025 at 05:44:14PM +0200, Michal Koutný wrote:
> > On Tue, Sep 16, 2025 at 10:47:56AM -0400, Aaron Tomlin <atomlin@...mlin.com> wrote:
> > > I would prefer not to take any action. However, is there a strong
> > > preference to demote the rt task so the CPU controller can be enabled in
> > > this context?
> > 
> > Maybe more context clarifies. The preference is not to end up in this
> > corner.
> 
> I see. If I understand correctly, in this context, are you suggesting to
> modify the identified task's scheduling class (e.g. to SCHED_NORMAL) so the
> CPU controller can be enabled?
> 
> > I wonder does this combination come from a distro or is it your custom
> > setup? I assume the latter (but I'm curious if there's such a distro), in
> > that case you likely want to have the cpu controller on v1 hierarchy. v1
> > usage is what the boottime switch is currently useful for, v2 de facto
> > doesn't support RT group scheduling as of today [1], v2 systems should
> > simply unset CONFIG_RT_GROUP_SCHED to avoid issues enabling cpu
> > controller.
> 
> Yes. Under Red Hat Enterprise Linux (RHEL) 9 Kconfig option
> CONFIG_RT_GROUP_SCHED and Cgroup version 2 is enabled by default.
> Albeit, upstream can disable SCHED_FIFO/SCHED_RT group scheduling at
> boot-time via rt_group_sched=.
>

 CONFIG_RT_GROUP_SCHED is not enabled in RHEL9 and later.  It was on in
 RHEL8 which also defaulted to cgroupv1.


Thanks,
Phil



> > HTH,
> > Michal
> > 
> > [1] This [2] didn't make it into tree thus I'd be reserved with the
> >     message printed in your patch too.
> > [2] https://lore.kernel.org/all/20250310170442.504716-11-mkoutny@suse.com/
> 
> I see. Understood.
> 
> 
> Kind regards,
> -- 
> Aaron Tomlin
> 

--