From: Sam Vilain (sam_at_vilain.net)
Date: Mon 13 Oct 2003 - 14:27:09 BST
On Sun, 12 Oct 2003 21:56, Herbert Poetzl wrote;
> I ripped the O(1) scheduler out of the -aa series
> for 2.4.23-pre7
Yikes! That's keen :-).
Funny, I've just been working on a port of ctx-18pre1 to 2.4.22-ac4.
I've added `knobs' to the bucket tunables via a /proc interface,
though it's less than ideal - only the values from new contexts may be
set. I did it this way because I had an example to work from -
http://www.kernel.org/pub/linux/kernel/people/rml/sched/sched-tunables/
It would be better if the functionality was incorporated into the
new_s_context syscall, so that it could be used to set the values on
an existing context.
A quick diff of my untested working version (all I'll say about it is
it compiles) is at:
http://vilain.net/linux/ctx/patch-2.4.22-ac4-ctx18pre1.UNTESTED
> http://vserver.13thfloor.at/Experimental/split-2.4.23-pre7-O1/
> then I rediffed the c17f to this 'new' kernel and
> basically replaced the scheduler changes by your
> patches for ctx17 ...
> the result is at:
> http://vserver.13thfloor.at/Experimental/split-2.4.23-pre7-O1-c17f/
Nice ... I'll try applying that last lot to Alan's tree too.
> well, it compiles and doesn't explode immediately
> when I start the kernel, but I guess you know more
> about the scheduler stuff than I, maybe you could
> have a look at it, and tune it somehow?
This is all I do to test it;
1. start 2 new sched locked contexts, and run "perl -e '1 while 1'" in
both of them. Their `bucket level', that is, in /proc/X/status:
ctxsched: %d/%d = (FR: %d per %d; ago %ld)
^^
should drop to 0 gradually (in ~12.5s with two greedy contexts and
the default settings). The processes should have ~50% of CPU each.
2. start 1 new sched locked context, and run another cpu hog in it.
In `vtop', you should see that process gets more CPU than the other
two contexts, and gradually as its bucket level drops to 0, it will
get the same and the processes will be on 33% each.
3. start 1 new sched locked context, and run another cpu hog in it.
It should start off with more time, and gradually move towards all
processes getting 25% of CPU time.
4. start another 4 CPU hogs in one of the contexts. They should each
drop to roughly 5% each reasonably rapidly, while the other 3
contexts still get 25% CPU each.
Obviously this only works because there are four contexts and each is
getting 1/4 of the issued CPU token.
As far as `tuning' it goes, this is why we need some way of setting
these per-s_context values with an ioctl or suchlike. If there are
too few or too many tokens being issued, then it can become quite
biased. Perhaps also some way of the kernel notifying when a context
has been `running on empty' for too long to give a hint that not
enough tokens are being dished out, or there is a context running
perl -e "fork while 1"
-- Sam Vilain, sam_at_vilain.netReal Programmers never "write" memos. They "send" memos via the network.