From owner-freebsd-hackers@FreeBSD.ORG Mon Feb 9 11:11:51 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 09B4316A4CE for ; Mon, 9 Feb 2004 11:11:51 -0800 (PST) Received: from lakemtao02.cox.net (lakemtao02.cox.net [68.1.17.243]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8C3EF43D1D for ; Mon, 9 Feb 2004 11:11:50 -0800 (PST) (envelope-from A.J.Caines@halplant.com) Received: from mail.halplant.com ([68.100.162.49]) by lakemtao02.cox.net (InterMail vM.5.01.06.05 201-253-122-130-105-20030824) with ESMTP id <20040209191148.WHPF19763.lakemtao02.cox.net@mail.halplant.com> for ; Mon, 9 Feb 2004 14:11:48 -0500 Received: by mail.halplant.com (Postfix, from userid 1001) id 827931D; Mon, 9 Feb 2004 14:11:49 -0500 (EST) Date: Mon, 9 Feb 2004 14:11:49 -0500 From: Andrew J Caines To: freebsd-hackers@freebsd.org Message-ID: <20040209191149.GD2860@hal9000.halplant.com> Mail-Followup-To: freebsd-hackers@freebsd.org References: <1076342789.b793fb20dkt@digitalme.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1076342789.b793fb20dkt@digitalme.com> Organization: H.A.L. Plant X-PGP-Fingerprint: C59A 2F74 1139 9432 B457 0B61 DDF2 AA61 67C3 18A1 X-Powered-by: FreeBSD 4.9-STABLE X-URL: http://halplant.com:88/ X-Yahoo-Profile: AJ_Z0 X-ICQ: 283813972 Importance: Normal User-Agent: Mutt/1.5.6i Subject: Re: [call for helpers!] Tuning for the Beaver Challenge X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Andrew J Caines List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Feb 2004 19:11:51 -0000 For your consideration, bearing in mind I haven't read all details of the challenge or the systems and therefore may suggest inappropriate, wrong or dangerous things: Custom kernel enabling only the hardware needed, all compiled in (no modules), but be careful with fancy looking options in LINT/NOTES. It may be prudent to hard code interrupts, flags and other parameters to avoid potential suboptimal automatic allocations (eg. all PCI devs on irq 9). Mount all filesystems with async, noatime and *enable softupdates*. Use carefully sized (ie. just big enough) mfs filesystems for any area with dynamically generated data such as temporary files, server scoreboards, etc. /tmp and /var/run, at least. If there's a foo_enable="NO" you put in rc.conf, then do so. Disable as much logging as possible at system and application level, at source or config or by logging to /dev/null. If you have to log, trim I/O to the minimum, maximise buffering and minimise overhead (eg. "-n" for syslog). If any DNS activity is needed, a local cache (eg. dnscache) can help, but so can a nicely populated /etc/hosts. Depending on the tests, it may be a good idea to have the hostname (fully and unqualified) associated with the loopback rather than the (primary) network interface. For the Java benchmarks, try all the implementations which work, including the emulated ones. If the storage is going to be striped over all five disks in hardware by the controller, then notion of putting data "on the outside of the disk" doesn't apply. In fact in this configuration it _may_ make sense to use one big filesystem and leave it to the OS to optimise the filesystem I/O. -Andrew- -- _______________________________________________________________________ | -Andrew J. Caines- Unix Systems Engineer A.J.Caines@halplant.com | | "They that can give up essential liberty to obtain a little temporary | | safety deserve neither liberty nor safety" - Benjamin Franklin, 1759 |