Re: [PATCH] sched: Relax a restriction in sched_rt_can_attach()

[Tejun Heo]

Hello, Peter.

On Tue, May 05, 2015 at 04:10:49PM +0200, Peter Zijlstra wrote:
> Imagine:
> 
> 	  root
> 	 /    \
> 	A      B
>        / \    / \
>       a1 a2  b1 b2
> 
> Now if they all have -1, I cannot set a bw on any except the leaf nodes
> ([ab][12]). Because the sum of child bw must strictly be smaller or
> equal to the parent bandwidth, and -1 if effective inf.
> 
> Similarly, if A has bw enabled I cannot create a new child with -1.
> Because above.
> 
> Now you can kludge around some of this, for example you can make the
> default depend on the parent setting etc.. But that's horribly
> inconsistent.

I don't think we can kludge this.  For all other resources, we're
defining the limits that can't be crossed so nesting them w/ -1 by
default is fine.  RR slices are different it that we're really slicing
up and guaranteeing a portion of something finite, so unlimited by
default thing doesn't really work here.

> So I really prefer not to go that way; if people use RR/FIFO they had
> better bloody know what they're doing; which includes setting up the
> system.

The problem is that this is tied to the normal cpu controller.  Users
who don't have any intention of mucking with RT scheduling end up
being dragged into it.  Given the strict nature of RR slicing, I'm
don't even think it's actually useful to make the slicing
hierarchical.  From cgroup's POV, it'd be best if RR slicing can be
detached.

> The whole RR/FIFO thing is so enormously broken (by definition; this
> truly is unfixable) that you simply _cannot_ automate it.

Yeah, exactly.

Thanks.

-- 
tejun
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/