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

Re: proc extension request: p_sched

From: Peter Kadau <peter.kadau@xxxxxxxxxxxxxxxx>
Date: Mon, 29 Dec 2003 13:47:53 +0100

Hi !

Some more thoughts/concerns.

    Right.  A simple set of function pointers in struct scheduler ought
    to cover about 90% of what needs to be done.  I'm sure that some functions
    may also have to be migrated into or out of kern_switch.c to properly
    compartmentalize the user process scheduling functions.
And what about the stuff in kern_synch.c ? I'm pretty sure that *some*
schedulers would like to have their own timer policy, but I rather would
not like to touch this now.
Is this something for stage 3 or even stage 4 ?

    We have a preemptable kernel... that's how interrupt threads are
    scheduled.  It isn't always preemptable... a critical section prevents
    preemption, but it's close enough such that we can achieve near
    hard realtime in the next 6 months as we clean up various pieces of
    code that stay in critical sections for very long periods of time
    (like an interrupt thread when it is running).
Yeah, but isn't it by design that DF *never* preempts a process that is
running in kernelspace ? AFAIK there are no (good) upper bounds on the duration
of a syscall - but this or preemption of the process would be needed for
a hard real-time process. Please be graceful if I missed again something here...

Something else that came up while I was looking at my stuff again: When I started this thread I just wanted to replace the normal priority handling. Even if we compartmentalize the scheduler, I had to duplicate code for realtime and idle priorities - not much of a deal, since it's both conceptually easy and only a few lines. But generally speaking, this could be an issue. The possible approaches I see are: 1. Leave as is, duplicate code. Simple and clean, but maybe someday annoying. 2. Make schedulers nested/hierarchical. This adds complexity both for the infrastructure and the runtime. I wouldn't do this now. But it is more flexible and code-sharing friendly. The second one could be introduced at a later stage, so we wouldn't lose this facility right away. Just something not to lose track on I think.



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]