On Tue, 19 May 2015, Aleksa Sarai wrote: > >> However, it should be noted that organisational operations (adding and > >> removing tasks from a PIDs hierarchy) will *not* be prevented. > > > > This is how you spell: broken controller. > > This has been discussed before. Organisational operations (i.e. > attaching to a cgroup) are not to be blocked by a cgroup controller in > the unified hierarchy. You simply can't escape out of a parent > cgroup's limit through attaching to a child cgroup (because you will > attach either before the fork checks against the cgroup [in which case > the child's limit is followed -- which means you also follow the > parent's limit] or after it checks [which means you'll hit the > parent's limit and won't be able to fork]). That's complete and utter nonsense. What has the parent limit to do with the overflow of the child limit? parent: limit 100 usecnt 80 child: limit 10 usecnt 10 So moving anything into child is violating the constraints and has to be refused. Anything else is just dirty hackery. Thanks, tglx -- 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
