Le Sun, 12 Jan 2014 11:09:15 -0800, Greg KH <gre...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
