Re: kernel info

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:On Thu, Oct 14, 2004 at 01:09:08PM +0000, Ryan Newman wrote:
:> Is DragonFly's kernel preemptive or non-preemptive ?
:
:That's a difficult technical question. The simple answer is no, the
:normal kernel is not preemptive, execution of a kernel thread normally
:occurs until it returns either to userland or tries to do something
:blocking. Think of M_WAITOK allocations or any attemp to get a token.
:
:The more refined answer is partly yes, because interrupts can actually
:preempt the active kernel thread, if those are not explicitly masked
:via critical sections or splXXX protection. Certain critical subsystems
:like the slab allocator for the M_NOWAIT case are non-blocking and
:preemption safe.
:
:You can somewhat compare the BSD soft interrupt system with the Linux RT
:extensions, as long as the interrupt is not included in any splXXX mask
:or the masked areas and all critical sections have a known upper bound,
:you get Hard Real Time for that interrupt (thread).
:
:Joerg

    Right.  With several Caveats, and that is the latency is going to be
    governed by (A) how long mainline code holds onto a critical section,
    and (B) APIC latencies, which can be horrendous.  

    How long a critical section is held is higly controllable and with a
    bit of work we could probably guarentee ~200ns or so of max latency.
    The APIC issue is harder.  The APIC is a piece of crap microcontroller
    and it can only deliver one interrupt at a time, and remains 'stuck'
    until the interrupt it delivered is acked.  We can ack the interrupt
    quickly enough, and we do, but the APICs microcontroller can have 
    latencies of several microseconds in complex situations and that can
    be a real problem.

    There are other overheads involved too, of course, such as thread
    switching overheads.  Intel's hyperthreading really screws up RTOS
    guarentees.

    A better way to deal with RTOS issues is to require a SMP box (or
    in modern terms, a multi-core cpu), and to simply dedicate a cpu
    to the RTOS functions.  One can then just run the RTOS scheduler on
    that cpu in a dedicated manner.

    But we aren't doing any of that, at least not right now.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>