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.
I still can't get that interactivity score out of my mind.
:Since I'm very fond of the responsiveness effects
:of ULE in fbsd-current,
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.
If this doesn't contradict some visions you have for scheduling which
might fit better in the big picture, I'd be glad to try that on my system.
I would need some advice too, concerning system startup issues.
That's why I ask first before trying to do superfluous work.
If this is complete nonsense please let me know as well.
It uses a fixed priority scheme but you have to keep in mind
that the fixed priorities are differentiating major subsystems,
not user processes.
OK, I got that. Even better after reading the lwkt_* stuff in sys/kern.
And it makes interactivity scores much simpler which has to deal with
userspace threads only.
Be sure not to confuse user priority based time slicing with preemption.
I'm rather confused that one could do that...
Campus der Max-Planck-Institute Tübingen
Netzwerk- und Systemadministration
Tel: +49 7071 601 598
Fax: +49 7071 601 616