[systemd-devel] dbus interface for disabling default cgroups

[Lennart Poettering]

On Mon, 14.02.11 13:24, Daniel Poelzleithner (poelzi at poelzi.org) wrote:

> 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

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.

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.

> > 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, 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.

> > 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.

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.

> > 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.

Well, I disagree.

> > 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.

> It may work, but it will just not be perfect, and for perfect you need
> configurations for at least different workloads.

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

> > 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.

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. As Andrey pointed out making the log level stuff
configurable during runtime with this would be a very good thing. If
that by side-effect makes you happy then great!

Lennart

-- 
Lennart Poettering - Red Hat, Inc.