A while ago I announced a hierarchical fair scheduler for 2.3. That
work has progressed since then, here are the main changes from the
initial release (detailed changelog available on the website):
- All known issues fixed;
- Support for all architectures, although only i386 has been tested;
- Dropped the HSFQ acronym from all user-visible parts (including
names of system calls). It was hard to even say, let alone remember
what it stands for (hierarchical start-time fair queueing, the
underlying algorithm).
The URL has changed to:
http://people.cornell.edu/pages/bdd2/fairsched/
State of the code: alpha. It's been extremely stable for me, but AFAIK
I'm the only person running it. The SMP support certainly needs
testing on a true SMP machine. If anybody decides to try it out, I'd
be very happy to hear from you.
I've also written a testing utility (also on the website). It does the
following: 1. generates a random scheduling tree with random weights;
2. starts a busy loop in each leaf node; 3. calculates the predicted
and actual work (number of iterations) done by each busy loop and
displays statistics. Here is an example run:
[root@wispa util-hsfq]# ./fairsched-test 3 20 7
> 1.00000
+-8-> 0.38462
| `-2-> 0.38462 (A)
`-5-> 0.61538
+-1-> 0.30769 (B)
`-1-> 0.30769 (C)
expected work actual work error granularity
A 588330445 588413071 0.00014 0.02600
B 470664356 463468402 -0.01529 0.03250
C 470664356 477777682 0.01511 0.03250
The command-line arguments mean "run 3 busy loops for 20 seconds, seed
the random number generator with 7".
A representation of the tree is given on top. Each line corresponds to
a node in the scheduling tree. The digit X in -X-> on each line is the
weight of the node. The fraction of CPU time this node expects to
receive is printed next. Leaf nodes are denoted by a letter in
brackets.
The expected and actual work columns are what they say. The error is
(actual - expected) / expected. The granularity is the maximum error
that can occur due to the discrete nature of scheduling - the maximum
timeslice for a process is 0.2 seconds, so the scheduler cannot divide
CPU time with bigger accuracy than this.
Best wishes,
Borislav
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/