New scheduler algorithm committed

[Matthew Dillon]

: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.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>