Thank you. These are two different things. They may have a relationship but they ate not the same, and pretending they are is a bad experience. On Apr 29, 2014 6:04 AM, "Serge Hallyn" <serge.hallyn@xxxxxxxxxx> wrote: > Quoting Michal Hocko (mhocko@xxxxxxx): > > On Mon 28-04-14 18:00:25, Serge Hallyn wrote: > > > Quoting Dwight Engen (dwight.engen@xxxxxxxxxx): > > > > On Wed, 23 Apr 2014 09:07:28 +0300 > > > > Marian Marinov <mm@xxxxxxxx> wrote: > > > > > > > > > On 04/22/2014 11:05 PM, Richard Davies wrote: > > > > > > Dwight Engen wrote: > > > > > >> Richard Davies wrote: > > > > > >>> Vladimir Davydov wrote: > > > > > >>>> In short, kmem limiting for memory cgroups is currently > broken. > > > > > >>>> Do not use it. We are working on making it usable though. > > > > > > ... > > > > > >>> What is the best mechanism available today, until kmem limits > > > > > >>> mature? > > > > > >>> > > > > > >>> RLIMIT_NPROC exists but is per-user, not per-container. > > > > > >>> > > > > > >>> Perhaps there is an up-to-date task counter patchset or > similar? > > > > > >> > > > > > >> I updated Frederic's task counter patches and included Max > > > > > >> Kellermann's fork limiter here: > > > > > >> > > > > > >> http://thread.gmane.org/gmane.linux.kernel.containers/27212 > > > > > >> > > > > > >> I can send you a more recent patchset (against 3.13.10) if you > > > > > >> would find it useful. > > > > > > > > > > > > Yes please, I would be interested in that. Ideally even against > > > > > > 3.14.1 if you have that too. > > > > > > > > > > Dwight, do you have these patches in any public repo? > > > > > > > > > > I would like to test them also. > > > > > > > > Hi Marian, I put the patches against 3.13.11 and 3.14.1 up at: > > > > > > > > git://github.com/dwengen/linux.git cpuacct-task-limit-3.13 > > > > git://github.com/dwengen/linux.git cpuacct-task-limit-3.14 > > > > > > Thanks, Dwight. FWIW I'm agreed with Tim, Dwight, Richard, and Marian > > > that a task limit would be a proper cgroup extension, and specifically > > > that approximating that with a kmem limit is not a reasonable > substitute. > > > > The current state of the kmem limit, which is improving a lot thanks to > > Vladimir, is not a reason for a new extension/controller. We are just > > not yet there. > > It has nothing to do with the state of the limit. I simply don't > believe that emulating RLIMIT_NPROC by controlling stack size is a > good idea. > > -serge > _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
