Re: scheduler

[Peter Kadau <peter.kadau@xxxxxxxxxxxxxxxx>]

Hi !

>     Well, kern_switch.c is definitely the place to do it.  The user process
>     scheduler is fairly well isolated in DragonFly.
But it still assumes an essentially 4BSD environment like given
in kern_synch.c et al. So to modularize it I think would require some
more effort.

>     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.
Argh, yes I was talking out of my ass. I meant instead of just having
queuebits and queue[NQS] additionally having nxqueuebits and
nxqueue[NQS] for the "next queue class" and adding only highpriority
(i.e. more than 20 away from the runnable with the least priority) and
interactive (to be defined by scoring) processes to some queue[i].
If queuebits is all zero bits, switch the structures.

>     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).
I was thinking about modifying the current one with this simple idea.
Maybe it is way too naive.

>     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.
I dreamt of that, but, uhm, wouldn't that mean you'll have to load a
mandatory module before booting ?

Well anyhow before considering this API idea I would like to try out
first whether my idea is worth the hassle at all. You are not saying
it is a priori nonsense so I'll go for it.

Cheers
Peter

--
<peter.kadau@xxxxxxxxxxxxxxxx>

Campus der Max-Planck-Institute Tübingen
Netzwerk- und Systemadministration

Tel: +49 7071 601 598
Fax: +49 7071 601 616