On Tue, Apr 17, 2001 at 10:18:34PM +0000, E.B. Dreger wrote:
> > 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?
There is a mechanism, yes. Whether or not it can be compared to the
Alpha's, I have no idea. :-) Intel provides documentation on-line detailing
somewhat how cache invalidating happens. Unfortunately, I lost the exact
URL in recent CURRENT crashes (ahhh, the irony of it all :-)), so you'll
have to dig a little.
> > 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.
Probably true, but then you really only need to task switch if
all the CPUs are busy. So, as you say somewhere earlier in this message,
"on a lightly loaded system," this actually won't be the case.
> > 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
> FreeBSD.
>
> 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.
See condition variables, as those are the closest I can think of
regarding what you described. They are implemented in -CURRENT.
> I hope that I'm not too far out of my league, here... :-)
>
>
> Eddy
>
> ---------------------------------------------------------------------------
>
> Brotsman & Dreger, Inc.
> EverQuick Internet / EternalCommerce Division
>
> Phone: (316) 794-8922
>
> ---------------------------------------------------------------------------
Later,
--
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
