From owner-freebsd-hackers Mon Jun 28 1:52:32 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from m4.c2.telstra-mm.net.au (m4.c2.telstra-mm.net.au [24.192.3.19]) by hub.freebsd.org (Postfix) with ESMTP id 1419A14CEE for ; Mon, 28 Jun 1999 01:52:25 -0700 (PDT) (envelope-from a.reilly@lake.com.au) Received: from m5.c2.telstra-mm.net.au (m5.c2.telstra-mm.net.au [24.192.3.20]) by m4.c2.telstra-mm.net.au (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id SAA14981 for ; Mon, 28 Jun 1999 18:52:23 +1000 (EST) X-BPC-Relay-Envelope-From: a.reilly@lake.com.au X-BPC-Relay-Envelope-To: X-BPC-Relay-Sender-Host: m5.c2.telstra-mm.net.au [24.192.3.20] X-BPC-Relay-Info: Message delivered directly. Received: from areilly.bpc-users.org (CPE-24-192-48-172.nsw.bigpond.net.au [24.192.48.172]) by m5.c2.telstra-mm.net.au (8.8.6 (PHNE_14041)/8.8.6) with SMTP id SAA02067 for ; Mon, 28 Jun 1999 18:52:22 +1000 (EST) Received: (qmail 13217 invoked by uid 1000); 27 Jun 1999 23:52:25 -0000 From: "Andrew Reilly" Date: Mon, 28 Jun 1999 09:52:25 +1000 To: Mike Smith Cc: Dan Moschuk , hackers@FreeBSD.ORG Subject: Re: Beating system usage down Message-ID: <19990628095225.A2389@gurney.reilly.home> References: <19990624121816.A17448@trinsec.com> <199906241934.MAA01020@dingo.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <199906241934.MAA01020@dingo.cdrom.com>; from Mike Smith on Thu, Jun 24, 1999 at 12:34:06PM -0700 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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