On Tue, May 05, 2015 at 10:18:38AM -0400, Tejun Heo wrote: > > 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. Note that you _could_ do the same thing with IO bandwidth; esp. with these modern no-seek-penalty devices this could make sense. > > 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. Like in the other mail; hierarchy still makes perfect sense for the container case. > > The whole RR/FIFO thing is so enormously broken (by definition; this > > truly is unfixable) that you simply _cannot_ automate it. > > Yeah, exactly. I don't think you're quite agreeing to the same reasons I am. My main objection to the whole SCHED_RR/FIFO thing as defined by POSIX is that it does not in fact allow the OS to do what an OS _should_ do, namely resource arbitration and control. The whole rt-cgroup controller tries to somewhat contain that, but fundamentally once you use RR/FIFO you've given up your system to userspace control -- which btw is why its usually limited to root. SCHED_DEADLINE avoids all these problems, at the cost of a more complex setup. But the fact that both need fixed portions of a limited total does not in fact mean they're broken. -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
