:* Matt Dillon <[EMAIL PROTECTED]> [010415 23:16] wrote:
:>                               For example, all this work on a preemptive
:>     kernel is just insane.  Our entire kernel is built on the concept of
:>     not being preemptable except by interrupts.  We virtually guarentee
:>     years of instability and bugs leaking out of the woodwork by trying to
:>     make it preemptable, and the performance gain we get for that pain
:>     is going to be zilch.  Nada.  Nothing.
:Pre-emption is mearly a side effect of a mutex'd kernel.
:The actual gains are in terms of parallel execution internally.
:Meaning if we happen to copyin() a 4 meg buffer we can allow more
:than one process to be completing some sort of work inside the
:kernel other than spinning on the giant lock.

    Switching-away while obtaining giant lock isn't a big deal, and
    not really 'preemption'.  Switching a task out in the middle of
    some random piece of code is preemption and our system isn't designed
    to handle it.  By trying to implement it, you are virtually guarenteed
    to introduce hundreds of bugs that will take years to find and fix.

    My understanding of the original BSDI code was that an interrupt could
    preempt the current process, but on completion (or if the interrupt
    blocked) the current process would resume on the same cpu... that
    is, the BSDI system only preempted for interrupts, which our
    codebase can accomodate just fine.

    I can see us doing some fancy process switching to avoid spinning on
    the giant lock.  But I can't see us reliably preempting a process sitting
    in some random piece of kernel code.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to