:* 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.
:
:--
:-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
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.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
