* Matt Dillon <[EMAIL PROTECTED]> [010417 14:07] wrote:
> :
> :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.

You seem to be more concerned with the implementation rather than
the goal.

The goal is to have a kernel that's able to have more concurrancy,
things like pre-emption and task switching on mutex collisions can
be examined and possibly changed later.

Once the mutexes are in place the underlying implementation can
change pretty easily from task switching always to only task
switching when the mutex is owned by the same CPU that I'm running
on. (to avoid spinlock deadlock)

I agree that task switching _might_ be a performance hit, however
that can be fixed by only task switching when in interrupt context.

A lot of things remain to be seen, but only if people like you sit
down and start working with the SMP team to achieve the main goal,
which is making the kernel MP safe for concurrant execution by
locking down the appropriate structures and code paths.

Instead of asking why a piece of software is using "1970s technology,"
start asking why software is ignoring 30 years of accumulated wisdom.

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

Reply via email to