However, Linus' comment that niceness levels are absolute, and you may want things to be more dynamic than that and fine-grained. For instance, if Xorg started being mean, you wouldn't want all your other processes to be destroyed. That's my understanding of that anyway.
Also, I think this issue is more complex than just scheduling of jobs, and there seems to have been a lot of improvements in actually making things more able to run in parallel, or in other words I think the multitasking ability of Linux just got a whole lot better with the recent coding that has gone into it. Being also able to make it so GUI responsiveness and user interaction in general gets higher priority is just one of the improvements.
Seriously, before all this, Linux had much worse multitasking capabilities than Windows 2000 did. Very happy to see this getting fixed.
For real good io scheduling linux 2.6.36 got a cgroup blkio subsystem.
Unfortunately it does not support deep hierarchy, so i need to run an own, flat mapping there.
But i hope that oom killer will never fire at all.
The GUI tasks should have a high priority, mainly the front window; audio should have a high priority too.
I'd like to make two points.
Guys, what are you talking about? Do you even realise a bunch of students can't write an OS scheduler! It's Operating System Science, a lot of research has been put into it, it's a highly theoretical and a very complex matter. It's not done overnight or in any way fast.
Desktop latency is a very complex issue, spawning across numerous subsystems, and the disorganised approach we have now in Linux, with new scheduler variants appearing every day, a few control daemons, and now this ULatencyD daemon being developed without necessary synchronisation and unified planning. Take a look at the Windows approach, for example:there the scheduler talks to the window manager and to some other subsystems, such as I/O and don't remember what else, dynamically adjusting itself and the process timeslice to the current situation. However, it is desktop-oriented, and this is where the window manager ties and the general quantum calculation and distribution algorithms originate. So we need to tackle this issue in a more broad and integrated way (not to be messed up with generic, that's another thing), and less UNIX/Linux (distributed/independent development) way, if you want.
This is what I mean:imagine some guy comes and says, "I want to introduce a mechanism for providing window manager feedback into the kernel a la Windows scheduler." Imagine the flame that comes right next to this? "It's not generic enough! We can't rely on a window manager in the kernel! We chanbge window managers every day! You're making too many assumptions, and this s not how Linux and UNIX in general is developed! Go go go develop your non-generic code somewhere else but not here! Never will it be included in the kernel!" And so on and so forth. We're too generic, and that's our problem. Sometimes you need to make compromises and develop something less generic and more exact, but solving some certain problem well instead of trying to be a jack of all trades and not succeeding in any of the problems you're trying to solve.
You seem to mix "multi-tasking" and "interactive performance".
Linux is -very- good at juggling huge amount of process on large amount of processing cores, In fact, it's -far- better than Windows Server 2K8 (Let alone Windows 2K).
However, as a desktop OS, Linux, at least out-of-the-box, is less optimized for interactive performance. (What is usually called responsiveness)
On the other hand, I spent parts of the weekend working (including gaming...) on my Xeon workstation while 16 out of the 24 (hyper)threads were busy compressing a 1.5TB storage into an external USB drive using tar+pbzip, so I guess Linux is not that bad when it comes to interactive performance....
DEV: Intel S5520SC, 2xX5680, 36GB, 5x320GB, GTX470, F19/x86_64, Dell U2711.
SRV: Tyan Tempest i5400XT, 2xE5335, 8GB, 4x2TB, 9800GTX, F19/x86-64, Dell U2412.
VCR: Gigabyte GA-M61PME-S2P, A64/5000X2, 2GB, 1x320GB, 8600GT, F19/x86-64.
LAP: ASUS N56VJ, i7-3630QM, 16GB, 1TB, 635M, F19/x86_64.
I just wanted to inform, that i made a real release 0.3.1
It got a lot of features since the project announcement. This release contains a plugin that detects the process of the active x window and gives those more cpu shares. And much more...
There is now a ubuntu PPA.
Xorg sure does use a lot of CPU. I wonder just how CPU-hungry Wayland will be in comparison. :P
so, even when x will not set the property on the menu windows, the focus information is not lost.
there are already rules that add ui apps of kde and gnome to a ui group that has more priority then any other running program, so switching desktops etc always feels fast.
xserver itself is placed in the group system.essential which gets lots of cpu shares.