[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130627180143.GD5599@mtj.dyndns.org>
Date: Thu, 27 Jun 2013 11:01:43 -0700
From: Tejun Heo <tj@...nel.org>
To: Mike Galbraith <bitbucket@...ine.de>
Cc: Tim Hockin <thockin@...kin.org>, Li Zefan <lizefan@...wei.com>,
Containers <containers@...ts.linux-foundation.org>,
Cgroups <cgroups@...r.kernel.org>,
bsingharora <bsingharora@...il.com>,
"dhaval.giani" <dhaval.giani@...il.com>,
Kay Sievers <kay.sievers@...y.org>,
jpoimboe <jpoimboe@...hat.com>,
"Daniel P. Berrange" <berrange@...hat.com>,
lpoetter <lpoetter@...hat.com>,
workman-devel <workman-devel@...hat.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: cgroup: status-quo and userland efforts
Hello, Mike.
On Thu, Jun 27, 2013 at 07:45:07AM +0200, Mike Galbraith wrote:
> I can understand some alarm. When I saw the below I started frothing at
> the face and howling at the moon, and I don't even use the things much.
Can I ask why? The reasons are not apparent to me.
> http://lists.freedesktop.org/archives/systemd-devel/2013-June/011521.html
>
> Hierarchy layout aside, that "private property" bit says that the folks
> who currently own and use the cgroups interface will lose direct access
> to it. I can imagine folks who have become dependent upon an on the fly
> management agents of their own design becoming a tad alarmed.
They're gonna be able to do what they've been doing for the
foreseeable future if they choose not to use systemd's unified
resource management. That said, what we have today is pretty lousy
and a lot of hierarchical stuff were completely broken until some
releases ago and things *must* have been broken on the userland side
too. It could have worked for their specific setup but I strongly
doubt there are anything generic working well out in the wild. cgroup
hasn't been capable of supporting something like that.
AFAICS, having a userland agent which has overall knowledge of the
hierarchy and enforcesf structure and limiations is a requirement to
make cgroup generally useable and useful. For systemd based systems,
systemd serving that role isn't too crazy. It's sure gonna have
teeting issues at the beginning but it has all the necessary
information to manage workloads on the system.
A valid issue is interoperability between systemd and non-systemd
systems. I don't have an immediately good answer for that. I wrote
in another reply but making cgroup generally available is a pretty new
effort and we're still in the process of figuring out what the right
constructs and abstractions are. Hopefully, we'll be able to reach a
common set of abstractions to base things on top in itme.
Thanks.
--
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