From owner-freebsd-hackers Tue Jun 10 10:53:04 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id KAA19947 for hackers-outgoing; Tue, 10 Jun 1997 10:53:04 -0700 (PDT) Received: from dyson.iquest.net (dyson.iquest.net [198.70.144.127]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id KAA19942 for ; Tue, 10 Jun 1997 10:52:58 -0700 (PDT) Received: (from root@localhost) by dyson.iquest.net (8.8.5/8.8.5) id MAA00375; Tue, 10 Jun 1997 12:52:44 -0500 (EST) From: "John S. Dyson" Message-Id: <199706101752.MAA00375@dyson.iquest.net> Subject: Re: Extremely poor interactive response under heave SCSI load In-Reply-To: <19970605184813.26023@crh.cl.msu.edu> from Charles Henrich at "Jun 5, 97 06:48:13 pm" To: henrich@crh.cl.msu.edu (Charles Henrich) Date: Tue, 10 Jun 1997 12:52:44 -0500 (EST) Cc: freebsd-hackers@FreeBSD.ORG Reply-To: dyson@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > Has anyone else noticed that a system with a large mount of unused (hence disk > cache) ram while under heavy SCSI load (or not so heavy really, e.g: > tar tvf crh.tgz > /tmp/crh.tgz.ls) causes interactive response to go into the > toilet, and any other disk I/O takes an eternity to complete? For example, > when doing that tar tvf of a 650mb file, it took over 30 seconds for mutt to > load and run, any operation that hit disk was delayed at least 30 seconds.. > Any ideas on a rememdy/tunable for this? (Im using an adaptec 2940) > There are a couple of potential causes for the problem. I have played with versions of the vfs_bio code that reserves a certain portion of the active cache for reads. It did help. The problem with adding it to the FreeBSD code base is that it is heuristic, and it would have to withstand signficant amounts of testing before burdening the users with it (the new "feature" :-)). John