> Date: Tue, 17 Apr 2001 14:52:06 -0700
> From: Alfred Perlstein <[EMAIL PROTECTED]>

Disclaimer: I am not a kernel hacker.

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

I think that Matt is saying, why bother?  Task switches are expensive.
With a heavily loaded system, the amount of time spent arbitrating mutexes
would exceed spin time.  With a lightly loaded system, do we really care
that much about spinning?

> 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

I'm not sure that I follow... if the task switch is on the same CPU, then
why do we need any new structures?  Without a global memory cache*, I
think that keeping processes on the same CPU is the first goal, anyway,
and increased concurrency second.

* Does Intel have any sort of cache coherency mechanism, where a processor
can tell other CPUs, "hey, this line is dirty" and the others retrieve the
new info as needed?  The Alpha?

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

Ughh.  AFAIK, traditional wisdom holds that interrupt loops should be as
short as possible.  Assuming that one performs quick operations, DMA
transfers, etc., preemptive task switching *would* be expensive.

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

Let's look at userland code.  I don't use async I/O because I don't want
to screw with interrupts and callbacks.  Polling of large structures?
Ughh.  Kernel queues are the solution, and what totally sold me on

How about basing things on *cooperative* multitasking?  All else being
equal, cooperative is faster because of lower overhead.  What makes co-op
break down is greedy programs that monopolize the CPU... but there should
not be any code like that in the kernel.

My instinct (whatever it's worth; remember my disclaimer) is that co-op
switching using something like tsleep() and wakeup_one() or similar would
be more efficient than trying to screw with mutexes.

However, perhaps that could be improved upon:  Use something a la kqueue
for portions of the kernel to say "I'm waiting for condition XYZ".  When
we wakeup_one(), we specify "for condition XYZ".  We could then avoid
waking processes that would only go back to sleep again.

I hope that I'm not too far out of my league, here... :-)



Brotsman & Dreger, Inc.
EverQuick Internet / EternalCommerce Division

Phone: (316) 794-8922


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

Reply via email to