Date: Tue, 05 Sep 2000 23:38:46 -0700 From: Peter Wemm <peter@netplex.com.au> To: The Hermit Hacker <scrappy@hub.org> Cc: freebsd-smp@FreeBSD.ORG Subject: Re: Sept 5th patch ... Message-ID: <200009060638.e866ckG49084@netplex.com.au> In-Reply-To: <Pine.BSF.4.21.0009060306200.572-100000@thelab.hub.org>
next in thread | previous in thread | raw e-mail | index | archive | help
The Hermit Hacker wrote: > > Sweet ... downloaded it tonight and installed it on my Dual-Celeron > ... smooth as can be ... > > Looking at the web site referenced in the status report posted on > -current, there are some old '97 benchmarks ... has anyone done anything > recent? More curious about before/after these patches ... > > I read that performance wasn't a key target for these changes, but > I'm wondering if there is there expected to be any performance > improvements just by the fact of the work that was done (ie. schedualer is > now better or some such) ... A buildworld, for example, is quite a bit slower (eg: 33 minutes -> 45 minutes on one particular quad xeon). But keep in mind that this is just about the worst possible way to do this. The reasons for doing it this way: 1: It gives us a validatable, stable, understandable baseline to work from. If something wierd happens, we have a baseline to fall back to and compare against. 2: This implements the basic functionality. Everything else is built on top of this and can be done in parallel from here on. 3: For example, fast interrupts can be done in parallel with other pushdown work (VFS, network, device drivers, etc). Performance is going to suck and stay sucking until the proper lazy context switch interrupt threads are done. We have the BSD/OS code to use as a template, but unlike BSD/OS we have a fallback in place to buy us time to debug the lazy context switch code. Remember, the i386 kernel is now running with *NO SUCH THING AS SPLxxx()* - interrupt handlers have to do a process context switch and compete for the giant lock while before doing their interrupt work. There is a lot of overhead ehere. Considering just how suboptimal this initial checkin will be, its been a pleasant suprise that it wasn't a larger impact than it is. We are expecting this and it will not take long to get it back to at meet or exceed the performance that it was at before. Other reentrancy improvements will offset the overheads imposed by the slow interrupt threads, so overall we will start winning long before we break even with interrupt code efficiency. Once the Alpha's interrupt threads are done, we can remove spl's from the source. On the i386 they will be do-nothing inlines or macros. The actual splxxx()/ splx() pairs will probably remain for a while as they are excellent markers of places that need to be checked for reentrancy. I personally am quite excited. Once it hits the tree, the number of developers who can be directly involved goes from "a few" to "everybody interested". Cheers, -Peter -- Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009060638.e866ckG49084>