Re: scheduler

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Hi !
:
:Well, it took some time, but I didn't lose track.
:I had to digest through some code first.
:
:> :Since I'm very fond of the responsiveness effects
:> :of ULE in fbsd-current,
:I still can't get that interactivity score out of my mind.
:And I wonder whether the current/next priority queue idea from ULE
:together with this scoring mechanism could be used in kern_switch.c.
:And that completely decoupled from other mechanisms of ULE,
:like event-driven scheduling (or so-called O(1)-scheduling), alternative
:aging of information or cpu migration/balancing, thusly leaving the 
:other infrastructure (essentially) untouched.
:
:The idea being simply this: instead of one time-sharing (tail)queue
:we'll have two (prority)queues current and next. The policy for
:realtime vs. time-sharing vs. idle is left intact.
:Inside time-sharing current is always served first and if it's empty
:both queues are switched just like in ULE. Each time a thread wakes up
:from a voluntary sleep its interactivitiy score is reevaluated as it is
:every 10 ticks in the course of FOREACH_PROC_IN_SYSTEM if it is runnable 
:at all. Rest as in ULE.

    Well, kern_switch.c is definitely the place to do it.  The user process
    scheduler is fairly well isolated in DragonFly.   

    The existing scheduler already uses a multi-queue approach.  There are
    three nearly identical scheduling classes (only the middle one, the
    'normal' scheduler has dynamic priority movement), and each scheduling
    class has 32 timeshare queues.

    ULE is a considerably more complex scheduler then 4BSD.  I'm not sure
    whether you are talking about taking our current scheduler and modifying
    the queueing mechanism or whether you are talking about pulling in ULE
    and then modifying it.  Generally speaking I would not recommend that
    you attempt to modify ULE... it's just too complex.  Instead I would
    recommend that you write a new scheduler from scratch using the 'API'
    in kern_switch() (i.e. the procedure call API).

    If you want to persue this with the intent of making it available in
    DragonFly, then I think the best way to benefit DragonFly would be
    to first adapt the current scheduler API into a KLD-loadable form.
    Then, second, develop your scheduler as a KLD.

						-Matt