-----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(a)redhat.com) 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-----