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 :| -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
