[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F87042A.2000902@parallels.com>
Date: Thu, 12 Apr 2012 13:34:50 -0300
From: Glauber Costa <glommer@...allels.com>
To: Frederic Weisbecker <fweisbec@...il.com>
CC: Johannes Weiner <hannes@...xchg.org>,
Hugh Dickins <hughd@...gle.com>,
Andrew Morton <akpm@...ux-foundation.org>,
KAMEZAWA Hiroyuki <kamezawa.hiroyu@...fujitsu.com>,
Tejun Heo <tj@...nel.org>, Daniel Walsh <dwalsh@...hat.com>,
"Daniel P. Berrange" <berrange@...hat.com>,
Li Zefan <lizf@...fujitsu.com>,
LKML <linux-kernel@...r.kernel.org>,
Cgroups <cgroups@...r.kernel.org>,
Containers <containers@...ts.linux-foundation.org>
Subject: Re: [RFD] Merge task counter into memcg
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.
>> > 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.
Is there anything for which you need to know exactly the number of
processes?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists