From mboxrd@z Thu Jan 1 00:00:00 1970 From: Frederic Weisbecker Subject: Re: [RFD] Merge task counter into memcg Date: Thu, 12 Apr 2012 18:59:27 +0200 Message-ID: <20120412165922.GA12484@somewhere.redhat.com> References: <20120411185715.GA4317@somewhere.redhat.com> <20120412010745.GE1787@cmpxchg.org> <20120412145507.GC11455@somewhere.redhat.com> <4F87042A.2000902@parallels.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=/r+rGpHfNvUpXOEzNF5ZR3kV93KKGUmvVqqffPXQHfI=; b=IzkSDqDh0Z2VLueNG6wxvkraKcYidfwe1ib8GxdJCAvFEbsnoaCJO8Hz+U6sHTM24a tlRXpbEwcHR9MB/biRLnKe+eie9nOtfKLSXBbP8g7GVdHc6MY6tk9+FuHUqm1iaU2sDM a3e7v4fzdfSZqAl9GsMwZHSdJjamsHSXM0O+zaSDIV9u7TmsqnOHSsjYWco/udjbJBGg P4JR24zPoOrxF5xHBp/2PUUnaTjxjm4sqfcrZmrWyDDo3u3gk+EkBio6Yx64U76YqtWW cqeFkvMNry6XVjCGkjbZ/OLPJFfufuXphnPRtZLe/T17/QoSc4SrUqtsZU+CZNDMo9g8 Cfgw== Content-Disposition: inline In-Reply-To: <4F87042A.2000902-bzQdu9zFT3WakBO8gow8eQ@public.gmane.org> List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: containers-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Glauber Costa Cc: "Daniel P. Berrange" , Containers , Daniel Walsh , Hugh Dickins , LKML , Johannes Weiner , Tejun Heo , Cgroups , Andrew Morton On Thu, Apr 12, 2012 at 01:34:50PM -0300, Glauber Costa wrote: > On 04/12/2012 11:55 AM, Frederic Weisbecker wrote: > >I don't know how the kernel stack is allocated for tasks. Do you mean > >that we allocate a chunck of it for each new task and we could rely > >on that? > > > More than this: amount of kernel stack is really, really something > indirect if what you want to track is # of processes. Now, Hannes > made a fair point in his other e-mail about what is a resource and > what is not. I start to consider this option, are there other people interested in accounting/limiting kernel stack as well? > > >>> After all, we would only restrict the number of tasks for the > >>> resources they require > >It depends if the kernel stack can have other kind of "consumer". > > > It also depends on what you really want to achieve. > If you want to prevent fork bombs, limiting kernel stack will do just fine. I want: a) to prevent the forkbomb from going far enough to DDOS the machine b) to be able to kill that forkbomb once detected, in one go without race against concurrent forks. I think a) can work just fine with kernel stack limiting. I also need to be notified about the fact we reached the limit. And b) should be feasible with the help of the cgroup freezer. > > Is there anything for which you need to know exactly the number of > processes? No that's really about prevent/kill forkbomb as far as I'm concerned.