On Wed, 20.07.11 15:20, Jason Baron (jbaron@xxxxxxxxxx) wrote: Heya, > The memory and cpu share controllers are currently supported (I simply haven't > gotten to supporting other controllers yet). One can add/delete cgroups, change > configuration parameters, and see which processes are currently associated > with each cgroup. There is also a 'usage' view, which displays graphically the > real-time usage statistics. The cgroup configuration can then be saved > into /etc/cgconfig.conf using the 'save' menubar button. How does it write that file? Does the UI run as root? That's not really desirable. It's not secure and it is cumbersome to mix applications running as differnt users on the same session and one the same X screen (since they cannot communicate with dbus, and so on). > Right now, the gui assumes that the various hierarchies are mounted separately, > but that the cpu and cpuacct are co-mounted. Its my understanding that this > is consistent with how systemd is doing things. So that's great. In F15 we mount all controllers enabled in the kernel separately. In F16 we'll optionally mount some of them together, and we'll probably ship a default of mounting cpu and cpuacct together if they are both enabled. > Currently, the gui saves its state using cgconfig.conf, and cgrules.conf. It > will display what libvirtd and systemd are doing, but will not save the state > for any of the cgroups that are created by libvirt or systemd. So, it > basically ignores these directories as far as persistent configuration. Thus, > it should not conflict with what systemd or libvirtd are doing. Quite frankly, I think cgrulesd is a really bad idea, since it applies control group limits after a process is already running. This is necessarily racy (and adds quite a burden too, since you ask for notifications on each exec()). I'd claim that cgrulesd is broken by design and cannot be fixed. > Thus, various privaleged consumers could make 'configuration requests' to a > common API, basically asking what's my configuration data. If there is already > data the consumer can proceed assigning tasks to those cgroups. Otherwise, it > can create a new request, which may or may not be allowed based upon the > available resources on the system. And each consumer can handle what it wants > to do in this case, which could potentially include tweaking the global > configuration. systemd is the first process of the OS after the initrd finished. At that time no other process is running, and that means it is not practical to have systemd talk to any other daemon to get the most basic of its functionality working. systemd is and will always have to maintain its own hierarchy independently of everybody else. In fact I think running som arbitration daemon which clients talk to to get a group created is a bad idea anyway: this makes things needless complex and fragile. If the main reason to do such a thing is to get events when the cgroup configuration changes then I'd much rather see changes made to the kernel so that we can get notifications when groups are created or removed. That could be done via netlink. Another option would be to hook cgroupfs up with fanotify. One of the nicer things of cgroups is that an "mkdir" is sufficient to create a group and an "echo $PID > $GROUP/tasks" to add a process to it. If you add complex systems on top of that which you need to talk to instead of trivial "mkdirs" and "open()+write()" you make cgroups much less attractive. Lennart -- Lennart Poettering - Red Hat, Inc. -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
