Re: Protection against container fork bombs [WAS: Re: memcg with kmem limit doesn't recover after disk i/o causes limit to be hit]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]