* 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.

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

Reply via email to