Johannes Weiner <hannes@xxxxxxxxxxx> writes: > On Mon, Jul 29, 2013 at 10:03:35AM -0700, Eric W. Biederman wrote: >> Yes. From the looks of the looks of it the cgroup implementation is >> rather badly borked right now, and definitely not up to the standards of >> the other core pieces of the kernel. One of the reasons I was rather >> apalled when systemd started using them. Until the code actually works >> reliably and the races are removed most people's systems would be much >> better off with cgroups compiled out. >> >> A single unified hierarchy is a really nasty idea for the same set of >> reasons. You have to recompile to disable a controller to see if it that >> controller's bugs are what are causing problems on your production >> system. Compiles or even just a reboot is a very heavy hammer to ask >> people to use when they are triaging a problem. > > That's not how it works. You can always select which controllers you > want to mount during runtime. Unified hierarchy only means that there > is one cgroup tree for all mounted controllers, rather than every > controller having its own separate cgroup tree. > > If you are like most users and currently mount all controllers in the > same directory so that their cgroup trees overlap and appear to be a > single tree, nothing changes for you. My practical need is that I need the ability modify which controllers I am using on a per group basis. So that I can make corrall new processes in a different set of controllers than currently existing processes. I might just be missing something but I don't see how to do that with all of the controllers mounted to the same filesystem. So while I currently have a single mount of cgroupfs, and don't yet see a need for orthogonal classification of processes. To keep bugs and craziness under control I expect I will be implementing a mount of cgroupfs per controller within a month. But except for the need to limit the scope of bugs this is all getting rather badly off topic. Eric -- 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