[systemd-devel] dbus interface for disabling default cgroups

[Daniel Poelzleithner]

On 02/14/2011 05:04 PM, Lennart Poettering wrote:

> I am not sure I actually buy that. I kinda like the fact that sending a
> signal to the gnome-shell process group delivers a signal to all
> processes it spawned.

But every program that execs another process may call setgrp on it's
child. Most shells for example do that, and console apps as well. Some
processes started by gnome-session run setsid and end up with different
task groups anyway, so you will never catch all.


> That said as soon as systemd takes over session management we actualy go
> much further: systemd services not only run in their own process group,
> but also in their own session.

thats perfect like it should be :-)

> Well, this remains a hack, and the higher your raise that value the more
> obvious it becomes: since all your slices summed up need to be < your
> period length you limit how many services/apps you can start. Since the
> period length by default is 1s, sending the runtime length to 1ms means
> you enforce a hard limit of 1000 groups controlled by you.
> 
> In short: this doesn't work. Fix the kernel. Don't try to work around
> broken kernel APIs in userspace.

As long as it's not fixed, I don't see any other solution :-)
But I'm thinking about moving all rt processes into one group, that will
be enough I think.

> Uh, this sounds wrong. You apply "rules" asynchronously on processes?
> How do you do that? With cn_proc? This is ugly and broken. Wasn't right
> in Upstart and is still broken outside of Upstart.

I use cn_proc as notifications for new processes and exits. I don't use
it for tracking where a process originated from, so it works quite nice
for this case. Using cgroups to find the origin is of course a much
better solution and cn_proc will not work there. But as I currently
don't care about origins, and in fact only schedule it when a process is
at least one second old, the cn_proc interface is much more suited then
cgroups.

rules only flag processes to help the scheduler making the best
decisions. Who the flags are weighted depends on the scheduler
configuration. New processes are scheduled after a delay of 1 second in
the default configuration, as many processes die very quickly with
absolutely no gain in running them through the pipeline. So, most
processes started will just stay in the cgroup of their parent and if
they stay longer, they will be optimized.


>>> The need for configuration is a bad thing, not a good thing. Where we
>>> can we should create systems that just work.
>>
>> I really think that "one configuration fits all" will just not work
>> until proven otherwise :-)
> 
> I believe we can get very very far without any heuristics and configured
> rules. So far you haven't listed any valid usecase where we couldnt come
> up with a generic logic that would work for everybody.

Example: i use the process group as the default grouping value which
works extremely good. Processes that belong together are usually in one
group, so one group of processes can't overload the system.
gnome-panel & kde don't set the process group, so i need a rule for
that. With the current configuration i can run a make -j 40 on the linux
kernel on my dual core and do not notice any slowdown, it's still smooth
everywhere.

Another example is the beloved swap of death. vlc leaks on some movies
and in the middle of the movie it stucks, I look down and see only the
harddisk driving mad. Sure i can press ctl+alt+f1 try to login, and
after like 10 minutes I will be able to kill it. Even worse: running a
group of programs that spawn may small tasks, everyone allocating a
little bit of memory. No oom will save you from that, instead he will
just kill some large important process like X :-)
And the desktop becomes very bad to use as all important stuff is
swapped out.
The current heuristics in ulatencyd protect me in both cases.

And again, of course it's better when everything is behaving good, but
if not, they never should be able to bring down a system, or even make a
impact that large that the desktop feels not right any more.

> Well, since you advocate workarounds your solutions are by definition
> imperfect. I think reaching perfection goes by fixing problems where
> they are...

The implemention may be imperfect, not the result. If I have to
implement a workaround for a bad behaving userspace program, thats fine
by me, but seening the program get fixed is of course the better solution.

> Well, i don't agree with your reasons, but yes, I would accept a patch
> that makes some properties of the Manager object writable, including
> defaultgroups. 

okily dokily :-)

kind regards
 Daniel

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 900 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20110214/ea0bf31a/attachment.pgp>