On Mon, 14.02.11 18:12, Daniel Poelzleithner ([email protected]) wrote: > 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.
Yeah, the chaos of what the various processes started by g-s do to detach from g-s is awful. we hope to clean this up a little with PR_SET_ANCHOR. > > 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 :-) Well the solution is to fix it then. > > 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. But that means you apply your cgroup magic only a posterio. That is by definition unsafe and unreliable. Using async interfaces for stuff like this is always broken. > >>> 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. Well, my famous shell fragment already kinda did that. As well as the autogrouping patch that got merged. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
