[systemd-devel] dbus interface for disabling default cgroups

[Daniel Poelzleithner]

On 02/14/2011 11:54 AM, Lennart Poettering wrote:

> I am not sure what you mean by "do not set the setpgid"? Do you want
> gnome-session to become its own session or the desktop services
> themselves?

gnome-panel for example should do a setpgid on the programs it starts as
they are logical new process group, that have nothing to do with ui
itself. gnome-session is a little bit different, some tasks should have
a new group, like the processes started from autostart, but others
belong to logically to the session.

https://bugzilla.gnome.org/show_bug.cgi?id=641387

> So, are you setting things to 1us, or 1ms?

1us, maybe i will increase it to 1ms. I will think about that. If the
process gets into a realtime group he gets of course a lot more.

> Well, ideally your entire pipeline should be RT if you do audio. For
> example, all Jack clients should have an RT thread. And that's already
> quite a few programs.

I will look into that, writing a helper rule that marks all processes
from a jack graph.

> Well, I don't buy that. I am working on something that is equally well
> suitable for all uses. I don't think that scalability in your solutions
> is impossible. The Linux kernel itself has already shown that it scales
> equally well to supercomputers and embedded devices.

The scheduler is scaling extremely well, no objection there. The point
is simply that it needs to be thought what's important to an user and
what's not. If I do a make -j whatever in an console, I don't want my
desktop ui to become slugish just because the scheduler is giving all
processes the same cpu shares. There are and ever will be processes that
are more important to the user. The program currently having focus is
more important then some random background task. Even assuming all
programs running behave nicely is just unworldly. When I run some very
cpu bound tasks, I still want my video to run without glitches. If
someone compiles a new kernel and wants to play a newer game while it's
running the priorities are clear: everything to the stuff necessary for
the game and whats left goes to the compiler. Thats what the user
expects and should get.
I strongly doubt that a solution for this works without lots of heuristics.

> 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 :-)
It may work, but it will just not be perfect, and for perfect you need
configurations for at least different workloads.

> Thankfully most distributions don't allow mucking around with other
> package's configurations from the install scripts of a different
> package.

Yes and thats a good thing. There is a reason why I wanted this dbus
call/property set. With it, there would be no need to change the
configuration when some program starts that will handle that. If a
program has root, he will be able to manipulate the cgroup tree anyway,
but when init always moves processes there first, it's just an annoying
clash. Nothing gained for anyone.

If you accept a patch making the DefaultGroups writeable, I will write
one. Even making a config variable to disable writeable.

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/f849eac0/attachment.pgp>