proc extension request: p_sched

[Matthew Dillon]

: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.
:
:Cheers
:Peter
:-- 
:<peter.kadau at xxxxxxxxxxxxxxxx>

    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.

					-Matt
					Matthew Dillon 
					<dillon at xxxxxxxxxxxxx>