Date: Tue, 17 Apr 2001 14:52:06 -0700 From: Alfred Perlstein <bright@wintelcom.net> To: Matt Dillon <dillon@earth.backplane.com> Cc: "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: <20010417145206.T976@fw.wintelcom.net> In-Reply-To: <200104172107.f3HL7ei07632@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Apr 17, 2001 at 02:07:40PM -0700 References: <200104160259.f3G2xqs06321@aslan.scsiguy.com> <200104160616.f3G6GI973782@earth.backplane.com> <20010417011957.W976@fw.wintelcom.net> <200104171722.f3HHMpt94518@earth.backplane.com> <20010417130210.K976@fw.wintelcom.net> <200104172051.f3HKpAF06881@earth.backplane.com> <20010417135336.Q976@fw.wintelcom.net> <200104172107.f3HL7ei07632@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Matt Dillon <dillon@earth.backplane.com> [010417 14:07] wrote: > > : > :You need to settle dude, pre-emption isn't a goal, it's mearly a > :_possible_ side effect. > : > :We're not aiming for pre-emption, we're aiming for more concurrancy. > > A goal of having more concurrency is laudable, but I think you are > ignoring the costs of doing task switches verses the likely spin time > for a mutex. The whole point of using fine-grained Mutexes is to not > have significant performance-effecting collisions in the first place, > so why bother to try to task switch if you wind up spining in one? > The goal for Giant is to get rid of it, so why bother to implement > preemption for Giant? The goal of taking an interrupt is to be able to > take several interrupts in parallel on different cpu's, and they can't > block anyway, so why try to turn interrupts into real threads? It just > doesn't make sense, Alfred. You guys are trying to optimize things that > don't need optimizing and my fear is that you will introduce so many > bugs into the kernel that it will take us years to get it back to 4.x's > level of reliability. The goals I see bandied about in the lists are > at cross-purposes with each other. You seem to be more concerned with the implementation rather than the goal. The goal is to have a kernel that's able to have more concurrancy, things like pre-emption and task switching on mutex collisions can be examined and possibly changed later. 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 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. 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. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom. 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?20010417145206.T976>