New scheduler algorithm committed
dillon at apollo.backplane.com
Thu Jun 30 15:29:23 PDT 2005
:Okay, I'm typing this in pine, running in a gnome-terminal window, and I see
:a solid improvement in responsiveness. Definitely useable again, even if not
:ideal. There is still some hesitation while echoing chars to the screen,
:but much improved, thanks!
:BTW, I think pine has little or nothing to do with this -- since I get the
:same lag when just typing chars into the gnome-terminal command line.
:I never mentioned before (but I'm sure you already know) than running the
:'buildworld' in an xterm window was always light-years better than running
:it in a gnome-terminal window.
:I've noticed that gnome-terminal allows you to click on any URL that is
:printed out in a gnome-terminal window -- so it must be parsing in real-time
:all of the text that passes thru its rather clumsy hands. I'm not at all
:sure that this is a valuable feature -- I'd vote for its removal.
:However, gnome-terminal's prinicpal asset is that it is a great benchmark
:for scheduler maintainers ;o)
Yah. gnome-terminal is a terrible cpu hog (actually, gnome in general
is a fairly bad cpu hog compared to e.g. kde). That makes it a fairly
good test of the scheduler but there's a limit to what a general purpose
scheduler can do when it has no specific hints from the user as to
what is batch and what is not.
I think I'm going to call it done, at least for the 'bsd4' scheduler.
The TODO list that's left mainly consists of abstracting out the SMP
operation and adding an API to allow switching to another scheduler on
the fly and for assigning different schedulers to different cpus (which
we can almost do already the way it is setup).
I'm going to take a break from it for a while, though. If someone else
would like to take up the ball please feel free to play! Else I'll
revisit it in a month or two.
<dillon at xxxxxxxxxxxxx>
More information about the Kernel