* 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

Reply via email to