From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f49.google.com (mail-wg0-f49.google.com [74.125.82.49]) by kanga.kvack.org (Postfix) with ESMTP id E4F476B0035 for ; Tue, 29 Apr 2014 17:45:00 -0400 (EDT) Received: by mail-wg0-f49.google.com with SMTP id x13so857824wgg.20 for ; Tue, 29 Apr 2014 14:45:00 -0700 (PDT) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [2a00:1450:400c:c00::229]) by mx.google.com with ESMTPS id z3si6359468wiw.1.2014.04.29.14.44.59 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 29 Apr 2014 14:44:59 -0700 (PDT) Received: by mail-wg0-f41.google.com with SMTP id y10so859902wgg.24 for ; Tue, 29 Apr 2014 14:44:59 -0700 (PDT) Date: Tue, 29 Apr 2014 23:44:56 +0200 From: Frederic Weisbecker 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] Message-ID: <20140429214454.GF6129@localhost.localdomain> References: <20140422200531.GA19334@alpha.arachsys.com> <535758A0.5000500@yuhu.biz> <20140423084942.560ae837@oracle.com> <20140428180025.GC25689@ubuntumail> <20140429072515.GB15058@dhcp22.suse.cz> <20140429130353.GA27354@ubuntumail> <20140429154345.GH15058@dhcp22.suse.cz> <20140429165114.GE6129@localhost.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org List-ID: To: Tim Hockin Cc: Michal Hocko , Serge Hallyn , Richard Davies , Vladimir Davydov , Marian Marinov , Max Kellermann , Tim Hockin , containers@lists.linux-foundation.org, Daniel Walsh , cgroups@vger.kernel.org, Glauber Costa , "linux-mm@kvack.org" , William Dauchy , Johannes Weiner , Tejun Heo , David Rientjes On Tue, Apr 29, 2014 at 09:59:30AM -0700, Tim Hockin wrote: > Here's the reason it doesn't work for us: It doesn't work. It was > something like 2 YEARS since we first wanted this, and it STILL does > not work. When I was working on the task counter cgroup subsystem 2 years ago, the patches were actually pushed back by google people, in favour of task stack kmem cgroup subsystem. The reason was that expressing the forkbomb issue in terms of number of tasks as a resource is awkward and that the real resource in the game comes from kernel memory exhaustion due to task stack being allocated over and over, swap ping-pong and stuffs... And that was a pretty good argument. I still agree with that. Especially since that could solve others people issues at the same time. kmem cgroup has a quite large domain of application. > You're postponing a pretty simple request indefinitely in > favor of a much more complex feature, which still doesn't really give > me what I want. What I want is an API that works like rlimit but > per-cgroup, rather than per-UID. The request is simple but I don't think that adding the task counter cgroup subsystem is simpler than extending the kmem code to apply limits to only task stack. Especially in terms of maintainance. Also you guys have very good mm kernel developers who are already familiar with this. -- 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