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

 Bosko Milekic

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

Reply via email to