From owner-freebsd-hackers Sun Jan 26 21:17:32 2003 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 76DBE37B401 for ; Sun, 26 Jan 2003 21:17:31 -0800 (PST) Received: from tomts14-srv.bellnexxia.net (tomts14.bellnexxia.net [209.226.175.35]) by mx1.FreeBSD.org (Postfix) with ESMTP id 983A043F18 for ; Sun, 26 Jan 2003 21:17:30 -0800 (PST) (envelope-from asr@softhome.net) Received: from Toronto-HSE-ppp3717089.sympatico.ca ([65.95.43.90]) by tomts14-srv.bellnexxia.net (InterMail vM.5.01.04.19 201-253-122-122-119-20020516) with ESMTP id <20030127051730.LPHF23890.tomts14-srv.bellnexxia.net@Toronto-HSE-ppp3717089.sympatico.ca>; Mon, 27 Jan 2003 00:17:30 -0500 Date: Mon, 27 Jan 2003 00:17:24 -0500 (EST) From: "Ashutosh S. Rajekar" To: Sean Hamilton Cc: Subject: Re: Random disk cache expiry In-Reply-To: <001801c2c5c0$5666de10$16e306cf@slugabed.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sun, 26 Jan 2003, Sean Hamilton wrote: > > In my case I have a webserver serving up a few dozen files of about 10 MB > each. While yes it is true that I could purchase more memory, and I could > purchase more drives and stripe them, I am more interested in the fact that > this server is constantly grinding away because it has found a weakness in > the caching algorithm. > > After further thought, I propose something much simpler: when the kernel is > hinted that access will be sequential, it should stop caching when there is > little cache space available, instead of throwing away old blocks, or be > much more hesitant to throw away old blocks. Consider that in almost all > cases where access is sequential, as reading continues, the chances of the > read being aborted increase: ie, users downloading files, directory tree > traversal, etc. Since the likelihood of the first byte reading the first > byte is very high, and the next one less high, and the next less yet, etc, > it seems to make sense to tune the caching algorithm to accomodate this. Your case seems to be a highly specific one, and would require very specific tuning. And then one will be able to find some other "unwanted behaviour" once you tune your system for particular behaviour. -ASR http://www.crosswinds.net/~rajekar MERYL STREEP is my obstetrician! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message