Here's the reason it doesn't work for us: It doesn't work. It was something like 2 YEARS since we first wanted this, and it STILL does not work. You're postponing a pretty simple request indefinitely in favor of a much more complex feature, which still doesn't really give me what I want. What I want is an API that works like rlimit but per-cgroup, rather than per-UID. On Tue, Apr 29, 2014 at 9:51 AM, Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote: > 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. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>