You need to settle dude, pre-emption isn't a goal, it's mearly a 
_possible_ side effect.

We're not aiming for pre-emption, we're aiming for more concurrancy.

* Matt Dillon <[EMAIL PROTECTED]> [010417 13:51] wrote:
> :
> :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]]
>     I wish it were that simple.   Remember when we went to shared file
>     descriptor arrays for processes?  Half a dozen serious bugs were 
>     introduced into the kernel from that change which weren't fixed for
>     over a year and half.  And that was *WITH* a Giant lock left intact.
>     A change to a single subsystem introduced 6+ serious bugs.  
>     Now you guys are introducing preemptive kernel scheduling and expect
>     it will be a walk in the park?  I expect it will introduce so many bugs
>     that the system will be destabilized for over a year, because that sort
>     of thing effects every single subsystem rather then just one or two.
>     It is not going to be as simple as throwing mutexes around every little
>     piece of code that might access shared state somewhere.  How many
>     mutex calls are we going to wind up making to implement the simplest 
>     system call now?  How much overhead are we going to introduce to support
>     a feature that isn't going to add one iota of performance to the system?
>     An incredible number of very cool optimizations can be made when you
>     have the ability to assume that the cpu you are running under will not
>     get ripped out from under you.  Things like per-cpu caching - not only
>     of mbufs or memory, but of other things as well.  Simple access to 
>     per-cpu globals now must suddenly be done with compare-exchange or
>     otherwise be required to use atomic instructions.   None of the current 
>     per-cpu variable handling code assumes that.
>     It's just not a good idea.  Do you want people to adopt -current when it
>     becomes 5.0?  It isn't going to happen if preemptive kernel scheduling
>     is in there.  I am going to wind up having to support 4.x for the next
>     two years before 5.x becomes reliable enough to use in a production 
>     environment.  Or, worse, -current is going to move down a path of 
>     no-return (becoming so unreliable that it will not be adopted by anyone)
>     and we are going to wind up having to scrap the whole damn thing!
>     I was somewhat skeptical about BSDI's interrupt-as-thread methodology, 
>     but at least they didn't bite of more then they could chew when they
>     implemented it.  Trying to extend that model to the Nth degree is
>     creating a huge mess -- and for what?  Just to support interrupts as
>     threads?  It isn't worth it.
>     I would much rather see us changing the interrupt model to be less
>     invasive, thus allowing interrupts to run unhindered as interrupts 
>     rather then threads, rather then see this preemptive kernel scheduling
>     stuff go in.  I love SMP, but I love stability more.  BSDI focused on
>     the things that actually effected performance.  -current is not focused
>     at all and is going off the deep end.. trying to do things that would
>     be interesting work for 5.2 or 5.3 but just plain should not be in 5.0.
>                                               -Matt

Represent yourself, show up at BABUG

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

Reply via email to