On Tue, 23.08.11 13:16, Vivek Goyal (vgo...@redhat.com) wrote:
> > Or to put this in other words: for systemd services are the focus, and
> > we'll create cgroups for them as one thing among many. In cgconfig
> > cgroups are the focus and how services are ordered into them only
> > secondary.
>
> Well, ideally one would like to have a mechanism so that one could
> also define what gets to run in the cgroup. That's where the notion
> of centralized mechanism to control comes in. But that also becomes
> complicated.
Well, you can tell systemd the cgroup path to place a service in. That
feature does exist.
This systemd service setting will place a service in
/foobar/waldo/quux/piep in
the "cpu" hierarchy:
ControlGroup=cpu:/foobar/waldo/quux/piep
Any you have full flexibility. systemd will do the equivalent of "mkdir
-p" to make sure the whole path exists.
With this you will not be able to set up groups that are not assigned to
a service and you are not able to set attributes in any of the parent
cgroups either. Which is why I believe cgconfig makes sense to use in
conjunction with systemd.
BTW, it would be cool if cgconfig would implement the sticky bit
semantics outlined here:
http://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups
So that systemd will never undo cgroup trees created by cgconfig.
> > http://lists.freedesktop.org/archives/systemd-devel/2011-August/003188.html
>
> This is off topic but I will mention though.
>
> BlockIOReadBandwidth=/home/lennart 5M
>
> I think above is little dangerous. What is /home/lennart is on btrfs
> which is backed by multiple devices. Would you put 5M limit on each
> device? But that is not same as saying /home/lennart has 5M bandwidth.
right now this option does not work on btrfs, since on btrfs stat()'s
st_dev will be zero and we need support for specific btrfs ioctls to
find the backing devices. But that's not implemented since I currently
have no btrfs partition around to test this against.
But I'd expect that this setting in the future would be applied to all
backing block devices. It's the only policy that makes sense, and if
people don't want that they should instead use explicit /dev/xxx rules
which gives trhem the full power to individually chose bandwiths for the
various devices if there are more than one.
> systemd will create its groups in top hierachy and cgconfig does not have
> any way to control them.
Nah, systemd only needs its own private name=systemd hierarchy. It will
by default duplicate the entire tree in "cpu", but you can easily turn
this off in which case cgconfig would be the only one creating cgroups
in the controller hierarchies. And then you could configure specific
systemd services to place themselves in the cgconfig-created tree via
ControlGroups=cpu:/my/path and so on.
Lennart
--
Lennart Poettering - Red Hat, Inc.
------------------------------------------------------------------------------
Get a FREE DOWNLOAD! and learn more about uberSVN rich system,
user administration capabilities and model configuration. Take
the hassle out of deploying and managing Subversion and the
tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
_______________________________________________
Libcg-devel mailing list
Libcg-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libcg-devel
