scheduler rewrite

[Matthew Dillon]

:
:That basically sounds like ULE to me. Do you plan to
:adapt ULE, make something separate but similar, or
:make something separate and radically different? (I
:suppose their might be some other in-between options
:too.) I was actually somewhat surprised by FreeBSD5's
:abandonment of ULE. I had been using it without any
:significant problems. Of course, if I was playing
:music, it sounded bad when I unpacked big port
:tarballs, but that happens with the old scheduler too.
:Anyway, I'm just looking for more info about what
:you're thinking about for the scheduler.
:
:Thanks,
:
:=====
:--
:Evan Dower

    No, we won't be adopting ULE.  I've written a dozen schedulers
    over the last 20 years, I can do a much better job IMHO then ULE.

    There have been discussions about the scheduler on this list in
    the past.  Basically it is a two-stage job.  The first stage would
    be to create an API to allow different userland schedulers to be
    loaded on-the-fly (on a live system), and possibly even allow multiple
    schedulers to operate in parallel.  This is possible because everything
    winds up being scheduled by LWKT at the lowest level anyway.  That is,
    the userland scheduler is only determining when user processes run and
    on what cpu they run and is not actually responsible for the mechanics
    of running the processes.

    The second stage would be to then write a new scheduler using the API.

    LWKT itself uses a strict fixed priority model and round-robins tasks
    running at the same priority.  This is the best model to use for
    kernel threads (interrupts, software interrupts, protocol threads,
    etc.  'user' threads usually have the lowest priority).

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>