[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120312225557.GK23255@google.com>
Date: Mon, 12 Mar 2012 15:55:57 -0700
From: Tejun Heo <tj@...nel.org>
To: Serge Hallyn <serge.hallyn@...onical.com>
Cc: Li Zefan <lizf@...fujitsu.com>,
containers@...ts.linux-foundation.org, cgroups@...r.kernel.org,
Michal Schmidt <mschmidt@...hat.com>,
Frederic Weisbecker <fweisbec@...il.com>,
Kay Sievers <kay.sievers@...y.org>,
linux-kernel@...r.kernel.org,
Lennart Poettering <lennart@...ttering.net>,
Andrew Morton <akpm@...ux-foundation.org>,
Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [RFD] cgroup: about multiple hierarchies
Hello,
On Mon, Mar 12, 2012 at 05:37:07PM -0500, Serge Hallyn wrote:
> Quoting Tejun Heo (tj@...nel.org):
> > Hello, guys.
> >
> > Thanks a lot for the discussion and here are my take aways:
> >
> > * At least to me, nobody seems to have strong enough justification for
> > orthogonal multiple hierarchies, so, yeah, unless something else
>
> First off, can you (sorry) show an example of exactly what would no
> longer be supported? Is this the ability to not separately mount
> freezer and cpusets (for instance)?
I think there are two aspects of it - there's actual functionality
loss and there's loss of one of the ways to achieve something.
The former is applying completely orthogonal categorizations to
processes depending on the controller in use - ie. memory limits by
user and disk IO limits by the program binary. AFAICS, nobody seems
to have strong enough justification for this.
The latter is probably more material. Even when people aren't using
orthogonal categorizations, they probably are using separate
hierarchies - currently, it's almost unavoidable to do so. So, that
part would be more painful. What I hope for is that some userland
system management tooling takes ownership of the cgroup fs interface
to impose some sane hierarchy and defaults, and expose more policy
aware interface to the rest of the system.
> I've submitted a topic for the upcoming linux foundation end user summit
> in new york, to get feedback from end users. (Frankly I don't want to go
> so would love if someone else wanted to do this :). I think it'd be nice
> to wait and see if this gets accepted, and see whether any end users are
> relying on this.
>
> (IMO it's wrong to say that "if you are using a current feature, you'd
> better be reading lkml so you can speak up lest that feature might get
> removed.")
Well, these mailing lists are the widest comm channel I can make use
of and I expect there to be people to chain and propagate the
communication to many different channels as necessary. So, yes, it
would be very appreciated if you can bring up the topic with larger /
different crowd. :)
Thank you.
--
tejun
--
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