Date: Tue, 17 Apr 2001 22:18:34 +0000 (GMT) From: "E.B. Dreger" <eddy+public+spam@noc.everquick.net> To: Alfred Perlstein <bright@wintelcom.net> Cc: 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: <Pine.LNX.4.20.0104172153020.11647-100000@www.everquick.net> In-Reply-To: <20010417145206.T976@fw.wintelcom.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> Date: Tue, 17 Apr 2001 14:52:06 -0700 > From: Alfred Perlstein <bright@wintelcom.net> Disclaimer: I am not a kernel hacker. > The goal is to have a kernel that's able to have more concurrancy, Right... > 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 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. 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 --------------------------------------------------------------------------- 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?Pine.LNX.4.20.0104172153020.11647-100000>