Date: Tue, 17 Apr 2001 15:36:12 -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: <20010417153612.W976@fw.wintelcom.net> In-Reply-To: <200104172200.f3HM0TI09802@earth.backplane.com>; from dillon@earth.backplane.com on Tue, Apr 17, 2001 at 03:00:29PM -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> <20010417145206.T976@fw.wintelcom.net> <200104172200.f3HM0TI09802@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
* Matt Dillon <dillon@earth.backplane.com> [010417 15:00] 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 > :on. (to avoid spinlock deadlock) > > That makes *NO* *SENSE* Alfred! So the first step is to introduce > every single possible feature under the sun, requiring massive reworking > of the code, even if it means the system becomes massively unstable, > inefficient, and starts crashing and burning, and then only *later* we > remove the features that don't pan out? That is the development model > you are using for -current? No I am not, what I'm trying to do is _use_ the APIs given to me to make the kernel more concurrent. I see no reason to abandon the external API, they are perfectly fine. You may disagree with the underlying implementation of the API and I think you may be right. (although afaik we're basing it on both Solaris and BSD/os's implementation so... well I'm not going to bother defending it.) I just wish you'd sit down and try to work adapting the VM to these APIs You're not going to get an arguement out of me about the underlying implementation of the mutexes as I really don't care right now. What I am going to argue is that argueing about the underlying implementation is a waste of time that could be better spent using the API to gain more concurrancy. > :I agree that task switching _might_ be a performance hit, however > :that can be fixed by only task switching when in interrupt context. > > WILL be a performance hit. WILL introduce major bugs. IS unnecessary, > DOESN'T make any sense whatsoever, is at CROSS PURPOSES with goals > already stated (not having any serious contention in the first place), > REQUIRES massive changes to the code with not a chance in hell of > producing an equivalent performance improvement for the trouble. > > There is no 'remains to be seen' here Alfred. This is setting up > -current for a fall, one that could be entirely avoided *now* > if you people would sit down and start thinking about what you are > doing. No, sitting down and spending many months hashing out the underlying mechnisms of what should be a pretty opaque API is a waste of time and will stagnate developement at much too great a cost. In fact, we sorta spent about 3 years doing it already haven't we? :) > > Remember when Dyson introduced ten thousand cool things all at once > and didn't debug them? Remember how long it took DG to the system > back into some semblence of shape after that? Remember that, even after > all that hard work, there were still literally hundreds of hard to find > bugs that DG couldn't find that it took Alan, DG, and I a year's worth > of work beyond all the work DG had already done to cleanup? Is that > what you want to happen to current? Because that is where current is > headed right now. Actually back then I wasn't that much of a kernel hacker, don't you remeber me standing there at SF BAFUG while you, Julian and Terry were discussing cache-coherency issues? I sort of had to take a break from listening to the lot of you because my brain went into overload, I was 19 or 20 at the time. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] Represent yourself, show up at BABUG http://www.babug.org/ 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?20010417153612.W976>