The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: luca abeni <luca.abeni@santannapisa.it>
To: Tejun Heo <tj@kernel.org>
Cc: Yuri Andriaccio <yuri.andriaccio@santannapisa.it>,
	Peter Zijlstra <peterz@infradead.org>,
	Yuri Andriaccio <yurand2000@gmail.com>,
	Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Steven Rostedt <rostedt@goodmis.org>,
	Ben Segall <bsegall@google.com>, Mel Gorman <mgorman@suse.de>,
	Valentin Schneider <vschneid@redhat.com>,
	linux-kernel@vger.kernel.org, hannes@cmpxchg.org,
	mkoutny@suse.com, cgroups@vger.kernel.org
Subject: Re: [RFC PATCH v5 20/29] sched/deadline: Allow deeper hierarchies of RT cgroups
Date: Thu, 14 May 2026 09:25:46 +0200	[thread overview]
Message-ID: <20260514092546.4265d486@luca64> (raw)
In-Reply-To: <b549b3cb062f2823ba6d4723b7b9260b@kernel.org>

Hi Tejun,

On Tue, 12 May 2026 08:19:02 -1000
Tejun Heo <tj@kernel.org> wrote:

> Hello,
> 
> How is a delegated subtree prevented from setting cpu.rt.min = 'root'
> and escaping its ancestors' cpu.rt.max budget?

If I understand well (please correct me :), the following strategy
should address this concern (and the ones expressed in successive
emails):
- cpu.rt.max can be "runtime, period" (or "runtime, period, deadline")
  or "root". "root" gives the current behaviour when RT cgroup
  scheduling is not enabled (so, no need to disable it at build time :)
  - if cpu.rt.max is "root", the cgroup's FIFO/RR tasks are scheduled in
    the root cgroup
  - if cpu.rt.max is "root", the children cgroups can only have "root"
    in cpu.rt.max
- if cpu.rt.max is not "root", then cpu.rt.min (or cpu.rt.internal)
  is "runtime, period" and describes the dl server for this cgroup's
  FIFO/RR tasks.
- The default value for cpu.rt.min is copied from cpu.rt.max, so as a
  default all the CPU utilization of the cgroup is dedicated it its RT
  tasks
- the admission test is: cpu.rt.min utilization plus the sum of the
  children's cpu.rt.max utilizations must be <= cpu.rt.max utilization;
  children can have cpu.rt.max="root" only if cpu.rt.max="root"

Can this work? I think it avoids escaping the parents' cpu.rt.max,
allows for a reasonable default (no-one should be forced to disable this
feature), and should respect all the requirements... Or am I missing
something?



			Thanks,
				Luca

  parent reply	other threads:[~2026-05-14  7:25 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20260430213835.62217-1-yurand2000@gmail.com>
     [not found] ` <20260430213835.62217-14-yurand2000@gmail.com>
2026-05-05 13:04   ` [RFC PATCH v5 13/29] sched/rt: Implement dl-server operations for rt-cgroups Peter Zijlstra
     [not found] ` <20260430213835.62217-15-yurand2000@gmail.com>
2026-05-05 13:16   ` [RFC PATCH v5 14/29] sched/rt: Update task event callbacks for HCBS scheduling Peter Zijlstra
     [not found] ` <20260430213835.62217-16-yurand2000@gmail.com>
2026-05-05 14:36   ` [RFC PATCH v5 15/29] sched/rt: Update rt-cgroup schedulability checks Peter Zijlstra
     [not found] ` <20260430213835.62217-19-yurand2000@gmail.com>
2026-05-05 14:59   ` [RFC PATCH v5 18/29] sched/core: Cgroup v2 support Peter Zijlstra
2026-05-06 19:58     ` luca abeni
2026-05-07  7:01       ` Peter Zijlstra
2026-05-07 13:30         ` luca abeni
2026-05-07 14:16           ` Peter Zijlstra
     [not found] ` <20260430213835.62217-20-yurand2000@gmail.com>
2026-05-05 15:01   ` [RFC PATCH v5 19/29] sched/rt: Remove support for cgroups-v1 Peter Zijlstra
2026-05-07 15:35     ` Juri Lelli
2026-05-13 12:15       ` Yuri Andriaccio
2026-05-13 14:37         ` Juri Lelli
     [not found] ` <20260430213835.62217-21-yurand2000@gmail.com>
2026-05-05 15:15   ` [RFC PATCH v5 20/29] sched/deadline: Allow deeper hierarchies of RT cgroups Peter Zijlstra
2026-05-05 19:56     ` Tejun Heo
2026-05-07 10:53       ` Peter Zijlstra
2026-05-07 15:03         ` Juri Lelli
2026-05-07 15:05           ` Peter Zijlstra
2026-05-07 16:39           ` luca abeni
2026-05-11  9:29             ` Juri Lelli
2026-05-11 17:52               ` Tejun Heo
2026-05-07 16:44         ` luca abeni
2026-05-11  9:40         ` luca abeni
2026-05-11 18:15           ` Tejun Heo
2026-05-11 17:37         ` Tejun Heo
2026-05-07 14:30       ` luca abeni
2026-05-11 18:28         ` Tejun Heo
2026-05-12 17:38           ` Yuri Andriaccio
2026-05-12 18:19             ` Tejun Heo
2026-05-12 18:20               ` Tejun Heo
2026-05-13 12:08                 ` Yuri Andriaccio
2026-05-13 19:10                   ` Tejun Heo
2026-05-14  7:25               ` luca abeni [this message]
     [not found] ` <20260430213835.62217-23-yurand2000@gmail.com>
2026-05-05 15:20   ` [RFC PATCH v5 22/29] sched/rt: Add rt-cgroup migration functions Peter Zijlstra
2026-05-05 15:24   ` Peter Zijlstra

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260514092546.4265d486@luca64 \
    --to=luca.abeni@santannapisa.it \
    --cc=bsegall@google.com \
    --cc=cgroups@vger.kernel.org \
    --cc=dietmar.eggemann@arm.com \
    --cc=hannes@cmpxchg.org \
    --cc=juri.lelli@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=mkoutny@suse.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tj@kernel.org \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=yurand2000@gmail.com \
    --cc=yuri.andriaccio@santannapisa.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox