Re: proc extension request: p_sched

[Peter Kadau <peter.kadau@xxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxx>

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

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