From owner-freebsd-current Tue Apr 17 18: 2: 3 2001 Delivered-To: freebsd-current@freebsd.org Received: from technokratis.com (modemcable092.3-201-24.mtl.mc.videotron.ca [24.201.3.92]) by hub.freebsd.org (Postfix) with ESMTP id CA57637B422 for ; Tue, 17 Apr 2001 18:01:58 -0700 (PDT) (envelope-from bmilekic@technokratis.com) Received: (from bmilekic@localhost) by technokratis.com (8.11.3/8.11.3) id f3I12e514918; Tue, 17 Apr 2001 21:02:40 -0400 (EDT) (envelope-from bmilekic) Date: Tue, 17 Apr 2001 21:02:40 -0400 From: Bosko Milekic To: "E.B. Dreger" Cc: Alfred Perlstein , Matt Dillon , "Justin T. Gibbs" , Doug Barton , "'current@freebsd.org'" Subject: Re: FW: Filesystem gets a huge performance boost Message-ID: <20010417210240.A14803@technokratis.com> References: <20010417145206.T976@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from eddy+public+spam@noc.everquick.net on Tue, Apr 17, 2001 at 10:18:34PM +0000 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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 bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message