On Sat, Oct 29, 2011 at 11:38:25AM +0200, Glauber Costa wrote:Well, ideally, I think we should put some effort in trying to reduce the number of different possible cgroups subsystems.On Sat, Oct 29, 2011 at 1:30 AM, Andrew Morton
<akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
On Tue, 25 Oct 2011 13:06:35 -0700
Tim Hockin<thockin@xxxxxxxxxx> wrote:
On Tue, Oct 4, 2011 at 3:01 PM, Andrew Morton<akpm00@xxxxxxxxx> wrote:On Mon, __3 Oct 2011 21:07:02 +0200
Frederic Weisbecker<fweisbec@xxxxxxxxx> wrote:
Hi Andrew,
This contains minor changes, mostly documentation and changelog
updates, off-case build fix, and a code optimization in
res_counter_common_ancestor().
I'd normally duck a patch series like this when we're at -rc8 and ask
for it to be resent late in -rc1. __But I was feeling frisky so I
grabbed this lot for a bit of testing and will sit on it until -rc1.
I'm still not convinced that the kernel has a burning need for a "task
counter subsystem". __Someone convince me that we should merge this!
We have real (accidental) DoS situations which happen because we don't
have this. It usually takes the form of some library no re-joining
threads. We end up deploying a few apps linked against this library,
and suddenly we're in trouble on a machine. Except, this being
Google, we're in trouble on a lot of machines.
This is a bit foggy. I think you mean that machines are experiencing
accidental forkbombs?
There may be other ways to cobble this sort of safety together, but
they are less appealing for various reasons. cgroups are how we
control groups of related pids.
In the end of the day, all cgroups are just a group of tasks. So I don't really
get the need to have a cgroup to control the number of tasks in the system.
Why don't we just allow all cgroups to have a limit on the number of
tasks it can hold?
Not sure what you mean. You would prefer to have this as a core feature in
cgroups rather than a subsystem?