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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
