On Tue, Apr 29, 2014 at 09:06:22AM -0700, Tim Hockin wrote: > Why the insistence that we manage something that REALLY IS a > first-class concept (hey, it has it's own RLIMIT) as a side effect of > something that doesn't quite capture what we want to achieve? It's not a side effect, the kmem task stack control was partly motivated to solve forkbomb issues in containers. Also in general if we can reuse existing features and code to solve a problem without disturbing side issues, we just do it. Now if kmem doesn't solve the issue for you for any reason, or it does but it brings other problems that aren't fixable in kmem itself, we can certainly reconsider this cgroup subsystem. But I haven't yet seen argument of this kind yet. > > Is there some specific technical reason why you think this is a bad > idea? > I would think, especially in a more unified hierarchy world, > that more cgroup controllers with smaller sets of responsibility would > make for more manageable code (within limits, obviously). Because it's core code and it adds complications and overhead in the fork/exit path. We just don't add new core code just for the sake of slightly prettier interfaces. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
