From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by kanga.kvack.org (Postfix) with ESMTP id C0FE66B0039 for ; Tue, 29 Apr 2014 10:04:11 -0400 (EDT) Received: by mail-vc0-f172.google.com with SMTP id id10so318824vcb.17 for ; Tue, 29 Apr 2014 07:04:11 -0700 (PDT) Received: from mail-ve0-x230.google.com (mail-ve0-x230.google.com [2607:f8b0:400c:c01::230]) by mx.google.com with ESMTPS id jb7si4530048vec.35.2014.04.29.07.04.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Apr 2014 07:04:11 -0700 (PDT) Received: by mail-ve0-f176.google.com with SMTP id db11so307283veb.7 for ; Tue, 29 Apr 2014 07:04:10 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20140429130353.GA27354@ubuntumail> References: <20140416154650.GA3034@alpha.arachsys.com> <20140418155939.GE4523@dhcp22.suse.cz> <5351679F.5040908@parallels.com> <20140420142830.GC22077@alpha.arachsys.com> <20140422143943.20609800@oracle.com> <20140422200531.GA19334@alpha.arachsys.com> <535758A0.5000500@yuhu.biz> <20140423084942.560ae837@oracle.com> <20140428180025.GC25689@ubuntumail> <20140429072515.GB15058@dhcp22.suse.cz> <20140429130353.GA27354@ubuntumail> Date: Tue, 29 Apr 2014 07:04:10 -0700 Message-ID: Subject: Re: Protection against container fork bombs [WAS: Re: memcg with kmem limit doesn't recover after disk i/o causes limit to be hit] From: Tim Hockin Content-Type: multipart/alternative; boundary=bcaec548a9b7f7a96f04f82ee7ca Sender: owner-linux-mm@kvack.org List-ID: To: Serge Hallyn Cc: Michal Hocko , Vladimir Davydov , Marian Marinov , Frederic Weisbecker , Johannes Weiner , containers@lists.linux-foundation.org, Tim Hockin , Glauber Costa , Tejun Heo , David Rientjes , linux-mm@kvack.org, Daniel Walsh , William Dauchy , Max Kellermann , cgroups@vger.kernel.org, Richard Davies --bcaec548a9b7f7a96f04f82ee7ca Content-Type: text/plain; charset=ISO-8859-1 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" wrote: > Quoting Michal Hocko (mhocko@suse.cz): > > On Mon 28-04-14 18:00:25, Serge Hallyn wrote: > > > Quoting Dwight Engen (dwight.engen@oracle.com): > > > > On Wed, 23 Apr 2014 09:07:28 +0300 > > > > Marian Marinov 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 > --bcaec548a9b7f7a96f04f82ee7ca Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Thank you.=A0 These are two different things.=A0 They may ha= ve a relationship but they ate not the same, and pretending they are is a b= ad experience.

On Apr 29, 2014 6:04 AM, "Serge Hallyn"= ; <serge.hallyn@ubuntu.com> wrote:
Quoting Michal Hocko (mhocko@suse.cz)= :
> On Mon 28-04-14 18:00:25, Serge Hallyn wrote:
> > Quoting Dwight Engen (= dwight.engen@oracle.com):
> > > On Wed, 23 Apr 2014 09:07:28 +0300
> > > Marian Marinov <mm@yuhu.bi= z> 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 cgr= oups is currently broken.
> > > > >>>> Do not use it. We are working on makin= g it usable though.
> > > > > ...
> > > > >>> What is the best mechanism available today= , until kmem limits
> > > > >>> mature?
> > > > >>>
> > > > >>> RLIMIT_NPROC exists but is per-user, not p= er-container.
> > > > >>>
> > > > >>> Perhaps there is an up-to-date task counte= r patchset or similar?
> > > > >>
> > > > >> I updated Frederic's task counter patches = and included Max
> > > > >> Kellermann's fork limiter here:
> > > > >>
> > > > >> http://thread.gmane.org/gmane.l= inux.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 a= t:
> > >
> > > git://github.com/dwengen/linux.git cpuacct-task-limit-3.13
> > > git://github.com/dwengen/linux.git cpuacct-task-limit-3.14
> >
> > Thanks, Dwight. =A0FWIW I'm agreed with Tim, Dwight, Richard,= and Marian
> > that a task limit would be a proper cgroup extension, and specifi= cally
> > that approximating that with a kmem limit is not a reasonable sub= stitute.
>
> The current state of the kmem limit, which is improving a lot thanks t= o
> Vladimir, is not a reason for a new extension/controller. We are just<= br> > not yet there.

It has nothing to do with the state of the limit. =A0I simply don't
believe that emulating RLIMIT_NPROC by controlling stack size is a
good idea.

-serge
--bcaec548a9b7f7a96f04f82ee7ca-- -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org