Date: Mon, 28 Jun 1999 09:52:25 +1000 From: "Andrew Reilly" <a.reilly@lake.com.au> To: Mike Smith <mike@smith.net.au> Cc: Dan Moschuk <dan@trinsec.com>, hackers@FreeBSD.ORG Subject: Re: Beating system usage down Message-ID: <19990628095225.A2389@gurney.reilly.home> In-Reply-To: <199906241934.MAA01020@dingo.cdrom.com>; from Mike Smith on Thu, Jun 24, 1999 at 12:34:06PM -0700 References: <19990624121816.A17448@trinsec.com> <199906241934.MAA01020@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 24, 1999 at 12:34:06PM -0700, Mike Smith wrote: > > Just for those that have been following the benchmarking thread, this > is exactly the same symptom set that FreeBSD demonstrates when loaded > by WebBench. The gotcha here is, again, the giant kernel lock. Rather than trying to do the Solaris thing of mutexing everything, why don't we go in the opposite direction, and configure a multi-processor box as a cluster that happens to have really fast communications? Probably not as easy as it sounds, particularly since it would involve writing a "memory network" device driver, and some boot code to partition the main memory, and probably an extra layer of interrupt handling code, to hand device interrupts around. Er, yuck. It's just that it sounds as though it would be simpler to start with a blank sheet and a clean reentrant scheduling scheme, and graft pieces of FreeBSD back on top, than it would be to add that sort of functionality onto an existing traditionally structured Unix. -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19990628095225.A2389>