On Mon, 14.02.11 13:24, Daniel Poelzleithner ([email protected]) 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. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
