On Thu, Jul 21, 2011 at 11:28:45AM -0400, Vivek Goyal wrote:
On Thu, Jul 21, 2011 at 03:52:03PM +0100, Daniel P. Berrange wrote:
> On Thu, Jul 21, 2011 at 10:36:23AM -0400, Jason Baron wrote:
> > Hi,
> >
> > On Wed, Jul 20, 2011 at 07:01:30PM -0400, Matthias Clasen wrote:
> > > On Wed, 2011-07-20 at 15:20 -0400, Jason Baron wrote:
> > > > Hi,
> > > >
> > > > I've been working on a new gui tool for managing and monitoring
cgroups, called
> > > > 'cg-manager'. I'm hoping to get people interested in
contributing to this
> > > > project, as well as to add to the conversation about how cgroups
should
> > > > be configured and incorporated into distros.
> > > >
> > >
> > > As a high-level comment, I don't think 'cgroup management' is
a very
> > > compelling rationale for an end-user graphical tool.
> > >
> > > For most people it will be much better to expose cgroup information in
> > > the normal process monitor. For people who want to use the specific
> > > cgroup functionality of systemd, it will be better to have that
> > > functionality available in a new service management frontend.
> >
> > I've thought that displaying at least the cgroup that a process is part of
would
> > be nice in the system monitor as well.
> >
> > I think its a question of do we want to make users go to a bunch of
> > different front end tools, which don't communicate with each other to
> > configure the system? I think it makes sense to have libvirt or
> > virt-manager and systemd front-end be able to configure cgroups, but I
> > think it would be also nice if they could know when the step on each
> > other. I think it would also be nice if there was a way to help better
> > understand how the various system components are making use of cgroups
> > and interacting. I liked to see an integrated desktop approach - not one
> > where separate components aren't communicating with each other.
>
> It is already possible for different applications to use cgroups
> without stepping on each other, and without requiring every app
> to communicate with each other.
>
> As an example, when it starts libvirt will look at what cgroup
> it has been placed in, and create the VM cgroups below this point.
> So systemd can put libvirtd in an arbitrary location and set an
> overall limits for the virtualization service, and it will cap
> all VMs. No direct communication between systemd & libvirt is
> required.
>
> If applications similarly take care to honour the location in
> which they were started, rather than just creating stuff directly
> in the root cgroup, they too will interoperate nicely.
>
> This is one of the nice aspects to the cgroups hierarchy, and
> why having tools/daemons which try to arbitrarily re-arrange
> cgroups systemwide are not very desirable IMHO.
This will work as long as somebody has done the top level setup and
planning. For example, if somebody is running bunch of virtual machines
and hosting some native applications and services also on the machine,
then he might decide that all the virt machines can only use 8 out of
10 cpus and keep 2 cpus free for native services.
In that case an admin ought to be able to do this top level planning
before handing out control of sub-hierarchies to respective applications.
Does systemd allow that as of today?
IIRC, you can already set cgroups configuration in the service's
systemd unit file, using something like:
ControlGroup="cpu:/foo/bar mem:/wizz"
though I can't find the manpage right now.
Regards,
Daniel
--
|:
http://berrange.com -o-
http://www.flickr.com/photos/dberrange/ :|
|:
http://libvirt.org -o-
http://virt-manager.org :|
|:
http://autobuild.org -o-
http://search.cpan.org/~danberr/ :|
|:
http://entangle-photo.org -o-
http://live.gnome.org/gtk-vnc :|