Re: proc extension request: p_sched

[Peter Kadau <peter.kadau@xxxxxxxxxxxxxxxx>]

Hi !

>     Theoretically any thread can set itself up to preempt mainline kernel threads,
>     the DFly preemption mechanism is generalized, but only interrupt threads use that
>     API right now (and I expect, generally speaking, only interrupt threads will
>     ever do this).
So which gives: hard real-time is not part of DF plans ? But theoretically
possible to implement (modulo the critical sections cleanup you were mentioning) ?
Don't get me wrong, I'm not heading towards this, I just want to understand your
remark about the possibility for userland schedulers.

>     Or, (3) Make the idle and realtime schedulers separate schedulers.  It
>     just happens that these schedulers can simply schedule threads at slightly
>     different LWKT priorities so an idle thread *always* has a lower priority
>     then the threads scheduled by other schedulers and a realtime thread *always*
>     has a higher priority then the threads scheduled by other schedulers, while
>     running in userland.
But you need the - currently implicit - ordering information e.g. in chooseproc.
(First check rtqueuebits etc.)
You couldn't let them just be handled by different schedulers, since lwkt-priorities
are fine for seperating the rtpriority types, but not for choosing a process
to be scheduled in the first place.
That's why I was speaking about nesting - otherwise this would have to be
hardcoded in the dispatcher functions like it is already in the current ones.
Since these semantics probably will never ever be subject to change
one could do that of course...

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