[systemd-devel] systemd and cgroups

[Dominique Michel]

Le Sun, 12 Jan 2014 11:09:15 -0800,
Greg KH <gregkh at linuxfoundation.org> a écrit :

> On Sun, Jan 12, 2014 at 06:10:34PM +0100, Dominique Michel wrote:
> > Last, this systemd patch is more than 3 years old now, and I also
> > just found that freedesktop is involved in that mess:
> > http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/
> > 
> > So, that imply, if I am right with my diagnostic, the next question
> > is what can be done to solve that issue?
> 
> I don't see a clear "issue" that you are asking about here, care to
> summarize it in a better way?

Well, at http://article.gmane.org/gmane.linux.kernel/1063354

"Lennart Poettering:

Well, this feature is... completely irrelevant for normal desktop
people.
...
In fact, I just prepped a patch to systemd to move every service and
every user session into its own cgroup in the 'cpu' hierarchy (in
addition to the group it already creates in the 'systemd'
hierarchy)."

Lennart show a total disrespect for the users by thinking his own user
case is the only one in the world. More:

"So, this patch (the kernel patch) only has an effect of people which
build kernels from an xterm with make -j all day, and at the same time
want to watch a movie, from a player they also start from a terminal,
but from another one."

I guess Lennart made a study off all possible combinations of all
cgroups with all available GNU/Linux commands lying around in order
to make that statement...

And he continue:
"In fact, I just prepped a patch to systemd to move every service and
every user session into its own cgroup in the 'cpu' hierarchy (in
addition to the group it already creates in the 'systemd' hierarchy). On
a system that runs systemd for both managing users and sessions this
means you are already half-way at what you want."

He concede this systemd patch is only half of what the kernel can do
when correctly used. I left the kernel/user space at side, because
this is not the idea to make that control of the cgroups in user space
that cause problem but its actual implementation.

And next:
"Well, if I make behaviour like this default in systemd, then this means
there won't be user setup for this. Because the distros shipping systemd
will get this as default behaviour."

In the kernel, it is other choices than that default, and the
combination of these choices and libcgroup made possible to adapt the
cgroups to any kind of work load. Which is obviously not the case of a
default behaviour without user setup. And never will.

I installed Debian it was a few months ago, and during the
installation, systemd was installed. My typical work load is to have
qjackctl in the autostart of my desktop, which start jackd or
jackdbus, and also gladish, as well than to have all my audio
applications using real-time priorities. With a few lines into
my .asoundrc, I interface the ALSA applications with JACK, that
without noticeable added latency, so I just don't need pulse. I also use
electronic simulation software like ng-spice, and to get the last
version, I compile it. For that reason, I don't want to double boot
between some kind of vanilla kernel and a rt kernel, I use the cgroups
to get rt priority for the audio.

That's explained here:
http://trac.jackaudio.org/wiki/Cgroups

All I need is one single cgroup with cpu.rt_runtime_us for the audio
applications.

I succeeded to make that to work on Debian with systemd, and it is here
the shit begun. Whatever I try, systemd was insisting to put anything
it think is good to have into that rt cgroup, and the result was the
same after each boot: after a variable amount of time, the system was
so frozen that even the magic keys was dead.

On the Debian forum, nobody was able to help me, not even with some
pointer on documentation. And normal, because according to Leenart,
it is no user setup for the cgroups. I am a normal desktop user that
just want to be able, in addition to electronic simulation, libreoffice
and stuffs like that, to be able to make some professional audio work
with his linux desktop. And thank to systemd default configuration
without user setup, it is just not possible any more to do
professional audio work for a casual desktop when systemd is installed.

I need that pc for production, so I rapidly installed another
distribution without systemd. So this problem is solved for me, but
that doesn't solve that to force any user to use a default
configuration without any possibility of user setup, and without
documentation that can allow an user to do that, is just a design fault.

Again, the point of the cgroups is to be able to adapt the system to
any kind of workload, and to have systemd that take control of that
good and flexible system, and at the same time, doesn't provide
a way for an user to adapt the default configuration to its own need,
is just a big design bug, which start with Lennart failure to
take in account the fact that all users are corner cases by
definition, because all users are doing different kind of works with
their computers.

Today, during a forum discussion on the cgroups, someone gave
the link above with the different Lennart's statements. I begun to
understand. Later also today, I finally find some documentation on
the freedesktop web site. But that's too late, I need this pc for
production, and I have other things to do than risking a hard disk
failure because of a freezing system, so I will not reinstall
Debian. And for that, I didn't even read more of that doc than a few
lines. I just lost the interest of the good idea that systemd is, that
because of its catastrophic implementation that can cause so severe
regression like system freeze, and its almost complete lack of
documentation. 

So, don't say me I could have done this or that, that's not my point. My
major point is GNU/Linux have always been about choices, and the actual
systemd implementation and lack of documentation is just removing the
possibility for the user to choose what he want do with the cgroups,
which can break the whole system apart when he try to do its own
cgroup configuration.

Regards,
Dominique

> 
> thanks,
> 
> greg k-h