DragonFly kernel List (threaded) for 2003-12
: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.