* Matt Dillon <[EMAIL PROTECTED]> [010417 10:22] wrote:
> :* 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.
There's actually very little code that non-premptable once we get the
kernel mutexed. The least complex way to accomplish this is to only
preempt kernel processes that hold no mutex (low level) locks.
-Alfred Perlstein - [[EMAIL PROTECTED]|[EMAIL PROTECTED]]
Represent yourself, show up at BABUG http://www.babug.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message