Maybe I'm naive but with an increasing number of individual cpu cores, couldn't different schedulers run on/manage different cpus? What would be needed to achieve that?
Osx, ootb, offers simply phenomenally consistent low latency. Same goes for iOS.
There was m excellent article about the deadline work on lwn awhile back. The key thing to understand is that it is designed specifically for periodic tasks (say making sure an audio/video buffer remains full during playback, or making sure a heartbeat is processed). This has been cooking for a long time and it's fantastic to see it finally appear outside of academia.
There are two main approaches I can see:
- kernel automagic (mr kolivas and his brainfuckscheduler BFS, DEADLINE, others...)
- automagic scheduling hacks (based on pam/consolekit - systemd)
If I may, I would like to point your atention towards ULATENCYD, which as of now, is feature complete, policy based (with working default policies) userspace scheduler that utilizes CGROUPS and other kernel subsystems (optionally BFS).
Code is here:
As I am writing this, I'm listening to youtube tracklist and runing kernel AND firefox compilation simultaneously with multiple jobs on laptop i5 while still having very decent responsiveness.Quote:
== What is ulatency ==
Ulatency is a daemon that controls how the Linux kernel will spend it's
resources on the running processes. It uses dynamic cgroups to give the kernel
hints and limitations on processes.
It strongly supports the lua scripting language for writing rules and the
== What tries it to fix ==
The Linux scheduler does a pretty good job to give the available resources to
all processes, but this may not be the best user experience in the desktop case.
ulatencyd monitors the system and categorizes the running processes into cgroups.
Processes that run wild to slow down the system by causing massive swaping will
== Isn't CONFIG_SCHED_DESKTOP enough ? ==
There is a patch for 2.6.38 in pipeline, see http://thread.gmane.org/gmane.linux.kernel/1050575
I think that this mimimal aproach is good for some circumstances, but does not
provide enough flexibility required for a true low latency desktop.
Perfect desktop scheduling needs a lot of heuristics, that don't belong in
the kernel. For example, the patch won't protect you from swap of death, fork bombs,
can't detect which process you are actually using and give more cpu shares to them,
can't give realtime priorities to processes like jackd, etc...
ulatencyd is designed for fixing exactly that.
Ulatency does all the magic as seen here:
Note that cpu shares are devided between several automatically scheduled processes (grp)Code:
$ ulatency --no-processes
│ ├─┬»grp_28316« cpu.shares=600
│ ├─┬»grp_9874« cpu.shares=600
│ ├─┬»grp_9186« cpu.shares=600
│ ├─┬»grp_9121« cpu.shares=600
│ ├─┬»grp_8831« cpu.shares=600
│ ├─┬»grp_7783« cpu.shares=600
│ ├─┬»grp_7780« cpu.shares=600
│ ├─┬»grp_6153« cpu.shares=600
│ ├─┬»grp_417« cpu.shares=600
│ ├─┬»grp_1000« cpu.shares=600
│ ├─┬»grp_998« cpu.shares=600
│ ├─┬»grp_21280« cpu.shares=600
│ ├─┬»grp_425« cpu.shares=600
│ ├─┬»bg_high« cpu.shares=1000
│ ├─┬»ui« cpu.shares=2000
│ ├─┬»grp_357« cpu.shares=600
│ ├─┬»grp_353« cpu.shares=600
│ └─┬»grp_23101« cpu.shares=600
and that my firefox (iso_firefox) and make batch jobs (iso_make) are on the same level as all other tasks in group usr_1000 and realtime tasks (pulseaudio among other things) but with different cpu.shares.
All this with basic to no configuration (apart from starting the daemon, sysvinit and systemd are supported).
I highly recommend ulatencyd, it works well for desktop and it's stable enough for desktop use.