Re: [RFC PATCH v5 20/29] sched/deadline: Allow deeper hierarchies of RT cgroups

[Yuri Andriaccio]

Hello,

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

Is it strictly required that a child cgroup must have 'less runtime' 
than its parent? To be more precise I mean scheduling tasks on the root 
runqueue instead of using dl-servers. Small note: given that HCBS 
cgroups use dl-servers, and thus run at higher priority than FIFO/RR 
scheduled on the root runqueue, if a cgroup rt.min is 'root' would yes 
escape its ancestor budget but it may also possibly get starved because 
of the priority levels.

If we require that child cgroups cannot escape their parent's bandwidth, 
even when using 'root', then the cpu.rt.max file must be disallowed in 
the root cgroup (removing the possibility to reserve bandwidth for HCBS, 
and so doing the admission test similarly to when SCHED_DEADLINE tasks 
are executed), and cpu.rt.max would use either 'root' if the whole 
subtree must be scheduled onto the root runqueue or a <runtime> <period> 
combination to reserve bandwidth for the whole subtree. The cpu.rt.min 
would then only be used to reserve internal bandwidth for the cgroup 
itself. This also means that a whole subtree either uses HCBS everywhere 
or the root runqueue everywhere.

> If the users on the system already started using rt, how do you 
enable the
> controller from the top down with budgets already being used down in the
> hierarchy?

In my original idea rt tasks would only interfere with their own cgroup 
configuration, but not with the subtree or their parents. When 
cpu.rt.min = 'root', you are free to change cpu.rt.max values to 
whatever you like in any place of the hierarchy, and tasks inside the 
rt.min = 'root' cgroup would not be affected as they are run in the root 
runqueue.

If you want to switch a cgroup from/to 'root' and HCBS, you'd have to 
either move all the RT tasks out of the cgroup, set rt.min, and then 
move them back in, or change temporarily their scheduling policy to 
non-rt (SCHED_OTHER, SCHED_DEADLINE, whatever) and then back.

Hopefully I've answered your questions. Which solution do you think 
makes the most sense?

Yuri