Since there is so much work currently ongoing with alternative cpu schedulers,
as a standard for comparison with the alternative virtual deadline fair
designs I've addressed a few issues in the Staircase Deadline cpu scheduler
which improve behaviour likely in a noticeable fashion and released version
0.41.http://ck.kolivas.org/patches/staircase-deadline/2.6.20.7-sd-0.41.patch
http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc7-sd-0.41.patchand an incremental for those on 0.40:
http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc7/sched-implem...Remember to renice X to -10 for nicest desktop behaviour :)
Have fun.
--
-ck
-
Oops forgot to cc a few people
Nick you said I should still have something to offer so here it is.
Peter you said you never saw this design (it's a dual array affair sorry).
Gene and Willy you were some of the early testers that noticed the advantages
of the earlier designs,
Matt you did lots of great earlier testing.
WLI you inspired a lot of design ideas.
Mike you were the stick.
And a few others I've forgotten to mention and include.--
-ck
-
(dirty job, somebody has to do it)
-
Version 0.42
http://ck.kolivas.org/patches/staircase-deadline/2.6.21-rc7-sd-0.42.patch
--
-ck
-
Will give it a shoot ASAP, probably this week-end. I'm too short in time this
week.Regards,
Willy-
Great, thanks. By then there will almost certainly be a 0.43 so no rush.
--
-ck
-
OK, I run some tests later today...
-
Thank you very much.
--
-ck
-
lmbench numbers are roughly comparable to mainline (lmbench seems to be
a bit erratic, but there isn't the obvious drop that cfs has).Didn't worry about hackbench ;)
kbuild:
2.6.21-rc7
508.87user 32.47system 2:17.82elapsed 392%CPU
509.05user 32.25system 2:17.84elapsed 392%CPU
508.75user 32.26system 2:17.83elapsed 392%CPU
508.63user 32.17system 2:17.88elapsed 392%CPU
509.01user 32.26system 2:17.90elapsed 392%CPU
509.08user 32.20system 2:17.95elapsed 392%CPU2.6.21-rc7-sd42
512.78user 31.99system 2:18.41elapsed 393%CPU
512.55user 31.90system 2:18.57elapsed 392%CPU
513.05user 31.78system 2:18.48elapsed 393%CPU
512.46user 32.06system 2:18.63elapsed 392%CPU
512.78user 31.81system 2:18.49elapsed 393%CPU
512.41user 32.08system 2:18.70elapsed 392%CPUsd42 is doing about 745 context switches per second here, and perfomance is
slightly below mainline. But it isn't doing badly.507.87user 32.53system 2:17.50elapsed 392%CPU
508.47user 32.40system 2:17.56elapsed 393%CPU
508.59user 32.27system 2:17.53elapsed 393%CPUA few runs with rr_interval at 100 show that ctxsw numbers drop to 587, and
performance is up to slightly above mainline.With the results I've got so far with all scedulers (actually I didn't try
nicksched with a small timeslice, but I'm sure it would give the expected
result)... I'd say 5ms might be too small a timeslice. Even 15ms will hurt
some people I think.Although we could arguably tolerate this kind of regression, my box only
has 1MB caches, and kbuild is naturally context switching at over 500 per
second anyway. On something with bigger caches and less context switchy /
more cache sensitive workloads, the regression could be quite a bit worse.(not directed at anyone in particular, but food for thought)
-
Great.
Not bad. It's always impossible to know where the sweet spot will lie with
these things. Basically the higher the better.... for this one thing ofWell they're nice numbers indeed. I don't even need to leave the maximum at
100ms but I seriously doubt we'd see much improvement beyond there... I'm
sure some renderfarm might enjoy values of 1 second though (like my -ck
patchet already offers in compute mode for old fashioned staircase cpuOn 4x (that's what your hardware was IIRC) SD would be setting it to 15ms.
Mainline would be timeslice granularity setting 4x to about 40ms. Pulling a
number out of my rear end generator I'd say 20ms for SD should make it closeHeck if I'm going to keep offering SD as an alternative for comparison I may
as well use the food you've offered me. I guess I better work on a v0.43 with
some more of these very easy to do tweaks then. Thanks!--
-ck
-
| H. Peter Anvin | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Eric W. Biederman | Remaining straight forward kthread API conversions... |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Frans Pop | svc: failed to register lockdv1 RPC service (errno 97). |
git: | |
