[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20100803132633.7cb720df@schatten.dmk.lab>
Date: Tue, 3 Aug 2010 13:26:33 +0200
From: Florian Mickler <florian@...kler.org>
To: Paul Menage <menage@...gle.com>
Cc: david@...g.hm, 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, 2 Aug 2010 21:41:17 -0700
Paul Menage <menage@...gle.com> wrote:
> 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
Ah yes, mea culpa. I've got this wrong.
Cheers,
Flo
--
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