proc extension request: p_sched

Peter Kadau peter.kadau at tuebingen.mpg.de
Mon Dec 29 04:49:22 PST 2003


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.
Cheers
Peter
--
<peter.kadau at xxxxxxxxxxxxxxxx>
Campus der Max-Planck-Institute Tübingen
Netzwerk- und Systemadministration
Tel: +49 7071 601 598
Fax: +49 7071 601 616





More information about the Kernel mailing list