On Mon, Apr 1, 2013 at 3:03 PM, Tejun Heo <tj@xxxxxxxxxx> wrote: > Hello, Tim. > > On Mon, Apr 01, 2013 at 02:02:06PM -0700, Tim Hockin wrote: >> We run dozens of jobs from dozens users on a single machine. We >> regularly experience users who leak threads, running into the tens of >> thousands. We are unable to raise the PID_MAX significantly due to >> some bad, but really thoroughly baked-in decisions that were made a >> long time ago. What we experience on a daily basis is users > > Ummmm.... so that's why you guys can't use kernel memory limit? :( Because it is completely non-obvious how to map between the two in a way that is safe across kernel versions and not likely to blow up in our faces. It's a hack, in other words. >> complaining about getting a "pthread_create(): resource unavailable" >> error because someone on the machine has leaked. > ... >> What I really don't understand is why so much push back? We have this >> nicely structured cgroup system. Each cgroup controller's code is >> pretty well partitioned - why would we not want more complete >> functionality built around it? We accept device drivers for the most >> random, useless crap on the assertion that "if you don't need it, >> don't compile it in". I can think of a half dozen more really useful, >> cool things we can do with cgroups, but I know the pushback will be >> tremendous, and I just don't grok why. > > In general, because it adds to maintenance overhead. e.g. We've been > trying to make all cgroups follow consistent nesting rules. We're now > almost there with a couple controllers left. This one would have been > another thing to do, which is fine if it's necessary but if it isn't > we're just adding up work for no good reason. > > More importantly, because cgroup is already plagued with so many bad > design decisions - some from core design decisions - e.g. not being > able to actually identify a resource outside of a context of a task. > Others are added on by each controller going out doing whatever it > wants without thinking about how the whole thing would come together > afterwards - e.g. double accounting between cpu and cpuacct, > completely illogical and unusable hierarchy implementations in > anything other than cpu controllers (they're getting better), and so > on. Right now it's in a state where there's not many things coherent > about it. Sure, every controller and feature supports the ones their > makers intended them to but when collected together it's just a mess, > which is one of the common complaints against cgroup. > > So, no free-for-all, please. > > Thanks. > > -- > tejun _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
