[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <w5z36gxgncmsoojht2upexrar7ooybaalg6s3gu4dugmnhvf2k@lqvh7feslsou>
Date: Fri, 19 Sep 2025 18:24:29 -0400
From: Aaron Tomlin <atomlin@...mlin.com>
To: Michal Koutný <mkoutny@...e.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 Wed, Sep 17, 2025 at 11:37:37AM +0200, Michal Koutný wrote:
> So I'd primarily suggest you to disable CONFIG_RT_GROUP_SCHED. It seems
> you ran into a situation where you have kernel with
> CONFIG_RT_GROUP_SCHED but userspace that'd like to use cgroup v2 and
> these two are known not get well along. (Alternatively, you may switch
> userspace to v1 if you really really need RT groups.)
Thanks Michal! I initially thought you were suggesting to "normalize" the
RT task in this context (e.g. a simplified version of
__sched_setscheduler()) to allow forward progress so the CPU controller can
be attached. Please ignore.
Kind regards,
--
Aaron Tomlin
Powered by blists - more mailing lists