Re: scheduler rewrite
:
: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@backplane.com>
討論串 (同標題文章)
完整討論串 (本文為第 4 之 10 篇)：