DragonFly BSD
DragonFly kernel List (threaded) for 2003-12
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: scheduler

From: Peter Kadau <peter.kadau@xxxxxxxxxxxxxxxx>
Date: Sat, 20 Dec 2003 13:50:50 +0100

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.



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

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

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]