[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3emv4bx2o7mdv7oc72ffdinlltqohqjt5nxgccdiyw47xjgbww@drvkcpiy5zq5>
Date: Tue, 16 Sep 2025 17:44:14 +0200
From: Michal Koutný <mkoutny@...e.com>
To: Aaron Tomlin <atomlin@...mlin.com>
Cc: 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 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.
> > What setup do you envision for this message? (CONFIG_RT_GROUP_SCHED and
> > cgroup v2?)
>
> Yes. At this point, RT_GROUP_SCHED would be enabled at runtime.
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.
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/
Download attachment "signature.asc" of type "application/pgp-signature" (266 bytes)
Powered by blists - more mailing lists