[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTinGjktpuNi8062BQPegr4mofF6bx2EfBAsbOhCe@mail.gmail.com>
Date: Mon, 2 Aug 2010 21:41:17 -0700
From: Paul Menage <menage@...gle.com>
To: david@...g.hm
Cc: Florian Mickler <florian@...kler.org>,
Arjan van de Ven <arjan@...radead.org>,
paulmck@...ux.vnet.ibm.com, "Ted Ts'o" <tytso@....edu>,
linux-pm@...ts.linux-foundation.org, linux-kernel@...r.kernel.org,
arve@...roid.com, mjg59@...f.ucam.org, pavel@....cz, rjw@...k.pl,
stern@...land.harvard.edu, swetland@...gle.com,
peterz@...radead.org, tglx@...utronix.de, alan@...rguk.ukuu.org.uk
Subject: Re: Attempted summary of suspend-blockers LKML thread
On Mon, Aug 2, 2010 at 2:06 AM, <david@...g.hm> wrote:
>
> yes, it could mean a doubleing in the number of cgroups that you need on a
> system. and if there are other features like this you can end up in a
> geometric explosion in the number of cgroups.
No, it would be additive - you can mount different subsystems on
separate hierarchies. So if you had X divisions for memory, Y
divisions for CPU and Z divisions for suspend-blocking (where Z=2,
probably?) you could mount three separate hierarchies and have X+Y+Z
complexity, not X*Y*Z.
(Not that I have a strong opinion on whether cgroups is an appropriate
mechanism for solving this problem - just that the problem you forsee
shouldn't occur in practice).
Paul
--
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