Date: Tue, 17 Apr 2001 21:02:40 -0400 From: Bosko Milekic <bmilekic@technokratis.com> To: "E.B. Dreger" <eddy+public+spam@noc.everquick.net> Cc: Alfred Perlstein <bright@wintelcom.net>, Matt Dillon <dillon@earth.backplane.com>, "Justin T. Gibbs" <gibbs@scsiguy.com>, Doug Barton <DougB@DougBarton.net>, "'current@freebsd.org'" <current@FreeBSD.ORG> Subject: Re: FW: Filesystem gets a huge performance boost Message-ID: <20010417210240.A14803@technokratis.com> In-Reply-To: <Pine.LNX.4.20.0104172153020.11647-100000@www.everquick.net>; from eddy%2Bpublic%2Bspam@noc.everquick.net on Tue, Apr 17, 2001 at 10:18:34PM %2B0000 References: <20010417145206.T976@fw.wintelcom.net> <Pine.LNX.4.20.0104172153020.11647-100000@www.everquick.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010417210240.A14803>