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

    A goal of having more concurrency is laudable, but I think you are 
    ignoring the costs of doing task switches verses the likely spin time
    for a mutex.  The whole point of using fine-grained Mutexes is to not
    have significant performance-effecting collisions in the first place,
    so why bother to try to task switch if you wind up spining in one? 
    The goal for Giant is to get rid of it, so why bother to implement 
    preemption for Giant?  The goal of taking an interrupt is to be able to
    take several interrupts in parallel on different cpu's, and they can't
    block anyway, so why try to turn interrupts into real threads?  It just
    doesn't make sense, Alfred.  You guys are trying to optimize things that
    don't need optimizing and my fear is that you will introduce so many
    bugs into the kernel that it will take us years to get it back to 4.x's
    level of reliability.  The goals I see bandied about in the lists are
    at cross-purposes with each other.


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

Reply via email to