From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marian Marinov 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] Date: Tue, 29 Apr 2014 16:57:44 +0300 Message-ID: <535FAFD8.1040402@yuhu.biz> 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> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=yuhu.biz; s=default; t=1398779865; bh=V0UcvCoAY7enB9Hl9B0aMBwnAIe8O/RtoI2R5WSkdTs=; h=Date:From:To:CC:Subject:References:In-Reply-To; b=G7rlj+dBxDOMqPa3dVOKo03tfvTzv/RLJ18cyRzoNZmVuVzVRSWxw+C/hBxPQUg4r G7W0Tcmda4exbPnxtAiL0dHq6sApprze51N7GK9tI1RWPnSq2QcQ3GX+b3Mpf9IUua fEOxoZ4+t3b/XZLIN6pNL4IOrjDfrzjdnx8tVbF8= In-Reply-To: <20140429130353.GA27354@ubuntumail> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: Serge Hallyn , Michal Hocko Cc: Richard Davies , Vladimir Davydov , Max Kellermann , Tim Hockin , Frederic Weisbecker , containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org, Daniel Walsh , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Glauber Costa , linux-mm-Bw31MaZKKs3YtjvyW6yDsg@public.gmane.org, William Dauchy , Johannes Weiner , Tejun Heo , David Rientjes On 04/29/2014 04:03 PM, Serge Hallyn wrote: > Quoting Michal Hocko (mhocko-AlSwsSmVLrQ@public.gmane.org): >> On Mon 28-04-14 18:00:25, Serge Hallyn wrote: >>> Quoting Dwight Engen (dwight.engen-QHcLZuEGTsvQT0dZR+AlfA@public.gmane.org): >>>> 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 I think that having a limit on the number of processes allowed in a cgroup is a lot better then relaying on the kmem limit. The problem that task-limit tries to solve is degradation of system performance caused by too many processes in a certain cgroup. I'm currently testing the patches with 3.12.16. -hackman