From owner-freebsd-hackers Thu Jan 30 16:37:39 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 1B11837B401 for ; Thu, 30 Jan 2003 16:37:38 -0800 (PST) Received: from ms-smtp-02.southeast.rr.com (ms-smtp-02.southeast.rr.com [24.93.67.83]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60F5343E4A for ; Thu, 30 Jan 2003 16:37:32 -0800 (PST) (envelope-from bts@fake.com) Received: from mail4.nc.rr.com (fe4 [24.93.67.51]) by ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h0V0aKo5006549; Thu, 30 Jan 2003 19:36:20 -0500 (EST) Received: from this.is.fake.com ([24.74.172.220]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Thu, 30 Jan 2003 19:38:32 -0500 Received: by this.is.fake.com (Postfix, from userid 111) id A8B5EBB33; Thu, 30 Jan 2003 19:37:12 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: "Brian T. Schellenberger" To: kientzle@acm.org, Matthew Dillon Subject: Re: Random disk cache expiry Date: Thu, 30 Jan 2003 19:37:11 -0500 User-Agent: KMail/1.4.2 Cc: Sean Hamilton , hackers@freebsd.org References: <000501c2c4dd$f43ed450$16e306cf@slugabed.org> <200301302222.h0UMMfFI090349@apollo.backplane.com> <3E39BE22.8050207@acm.org> In-Reply-To: <3E39BE22.8050207@acm.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200301301937.12407.bschellenberger@nc.rr.com> 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 Thursday 30 January 2003 07:06 pm, Tim Kientzle wrote: | Matthew Dillon wrote: | > Your idea of 'sequential' access cache restriction only | > | > works if there is just one process doing the accessing. | | Not necessarily. I suspect that there is | a strong tendency to access particular files | in particular ways. E.g., in your example of | a download server, those files are always | read sequentially. You can make similar assertions | about a lot of files: : : For example, if a process | started to read a 10GB file that has historically been | accessed sequentially, you could immediately decide | to enable read-ahead for performance, but also mark | those pages to be released as soon as they were read by the | process. I think you missed Matt's point, which is well-taken: Even if everybody accesses it sequentially, if you have 100 processes accessing it sequentially at the *same* time, then it would be to your benefit to leave the "old" pages around because even though *this* process won't access it again, the *next* process very well might, if it just happens to be reading it sequentially as well but is a little further behind on its sequential read. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message