What is SD?
SD stands for Staircase Deadline and it is the new name of RSDL. Thus the RSDL design docs are the same. This space is now reserved for a short but clear explanation of the why of another scheduler (SD/RSDL).
What is RSDL?
This is a cpu scheduler design I invented from the ground up based on some of the staircase ideas and quite a few new ones.
- Virtually immune to any starvation mechanism.
- Absolutely no runtime interactivity estimation or bonus mechanism.
- Virtually complete cpu distribution fairness based on nice.
- Low latency with a virtual deadline mechanism.
- Solid interactivity within the confines of the above.
Using 'nice' on this cpu scheduler should be very effective at metering out appropriate amounts of cpu and latency.
In summary it is an O(1) dual array bitmap lookup based system for creating a minimal overhead earliest eligible virtual deadline first design.
What is wrong with the current kernel scheduler?
It fails to provide 100% interactivity all the time. Not only that but it is far far less forgiving of the many userspace applications that do not have the luxury of extremely high performance userspace programming techniques, locking and thread manipulation ie just about all games for example, especially wine+games where you have no control over the original code. There are lots of servers that don't do that either (like the ldap server - see the lkml flamewars on that).
It's not the occasional stalls in userspace that are a problem but real world workloads that cause complete starvation of some userspace programs at extremely light loads (mainline is starveable at loads of 1). That is singularly unacceptable.
What are SD's costs, then? Lower performance/throughput?
There is no lower throughput. Only the one case someone reported with the CVS version of an audio encoder which I could not reproduce. The bigger benchmarks like the database and httpd ones actually show better throughput with SD. Also with the tunable rr_interval it's possible to push it further but some compromise needs to be chosen as a default. It's almost certain that increasing rr_interval will improve that one single workload reported with lower throughput. Note that if it's overall a gain on more workloads then it is satisfactory for a very few losses (but as I said, a tunable can fix that already).
You said in your first announcement RSDL and thus SD will never be as interactive as staircase was. Do we really want SD on the desktop?
Well, yes since desktop users see stalls due to the starvation. They also see sound dropouts in games. The unpredictable behaviour of interactive schedulers bite there too.