-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 07/21/2011 12:36 PM, Lennart Poettering wrote: > On Thu, 21.07.11 11:28, Vivek Goyal (vgoyal@xxxxxxxxxx) wrote: > >>> 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? > > Right now, systemd only offers you to place services in the cgroups > of your choice, it will not configure any settings on those cgroups. > (This is very likely to change soon though as there is a patch > pending that makes a number of popular controls available as native > config options in systemd.) > > For the controllers like "cpuset" or the RT part of "cpu" where you > assign resources from a limited pool we currently have no solution > at all to deal with conflicts. Neither in libcgroup and friends, not > in systemd, not in libvirt. > > However, I do think that figuring out the conflicts here is something > to fix at the UI level -- and systemd itself (or libvirt) should not > have to deal with this at all. The UIs should figure that out > between themselves. I think it should be possible to come up with > really simple schemes to deal with this however. For example, have > every UI drop in some dir /var/lib or so a file encoding which > resources have been taken and should not available in the other UIs > anymore, maybe with a descriptive stirng, so that those UIs can show > who took it away. > > However, I believe that adding something like that should be the > last step to care for in a UI. So far systemd doesn't have any > comprehensive UI. How to deal with conflicts between resource > assignments is not a central problem that would justify moving all > the consumers of cgroups on some additional middleware. > >> To allow that I think systemd should either provide native >> configuration capability or build on top of existing libcgroups >> constructs like cgconfig, cgrules.conf to decide how an admin has >> planned the resource management and in what cgroups services have >> to be launched, IMHO. > > For the systemd case I'd assume that a UI which wants to enable the > admin to control cgroup limits would just place a unit file for the > respective service in /etc/systemd/system, use ".include" to pull in > the original unit file, and set the setting it wants to set. > > Lennart > One goal I have for sandbox would be to allow it to plug into the cgroups hiearchy also. So a user could say I want to run all my sandboxes in such a way that they can only use X% of my CPU and Y% of memory. Allowing a user to always be able to kill the sandbox. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk4ohGwACgkQrlYvE4MpobONCQCfSX64iqXWKCokiuG8/ehxfl3L pTsAn3iRyJJNADkeY9O/osOrqcdPRL96 =aq0Q -----END PGP SIGNATURE----- -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
