DragonFly kernel List (threaded) for 2003-12
Re: proc extension request: p_sched
: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...
DF *will* preempt a thread that is running in kernelspace with another
thread, but only interrupt threads can do this. When the interrupt thread
completes or blocks it immediately resumes the originally preempted thread.
That is, even though interrupts are threads in DFly, they can still preempt
the kernel just like they did in 4.x.
In FreeBSD-5.x (1) any thread can preempt any other thread in the kernel,
(2) when an interrupt thread blocks it may schedule other (possibly non-interrupt)
threads before resuming the originally interrupted thread and (3) a kernel thread
can be ripped out from under its current cpu and moved to another cpu preemptively.
In DFly (1) only an interrupt thread can preempt other kernel threads, (2) when
an interrupt thread blocks it immediately resumes the originally preempted thread
without switching to other non-interrupt threads first and (3) a kernel thread
*cannot* be moved to another cpu while running, blocked, or preempted in the kernel.
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).
: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.
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.