From owner-freebsd-hackers Mon Jan 27 6: 5:24 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 2429D37B401 for ; Mon, 27 Jan 2003 06:05:22 -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 13A9A43F13 for ; Mon, 27 Jan 2003 06:05:14 -0800 (PST) (envelope-from bts@fake.com) Received: from mail3.nc.rr.com (fe3 [24.93.67.50]) by ms-smtp-02.southeast.rr.com (8.12.5/8.12.2) with ESMTP id h0RE44oB025537; Mon, 27 Jan 2003 09:04:07 -0500 (EST) Received: from this.is.fake.com ([24.74.172.220]) by mail3.nc.rr.com with Microsoft SMTPSVC(5.5.1877.757.75); Mon, 27 Jan 2003 09:03:37 -0500 Received: by this.is.fake.com (Postfix, from userid 111) id 206AABBC8; Mon, 27 Jan 2003 09:04:44 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: "Brian T. Schellenberger" To: kientzle@acm.org Subject: Re: Random disk cache expiry Date: Mon, 27 Jan 2003 09:04:43 -0500 User-Agent: KMail/1.4.2 Cc: Sean Hamilton , hackers@freebsd.org References: <000501c2c4dd$f43ed450$16e306cf@slugabed.org> <200301270019.44066.bschellenberger@nc.rr.com> <3E34C734.8010801@acm.org> In-Reply-To: <3E34C734.8010801@acm.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <200301270904.43899.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 The suggestion here basically boils down to this: if the system could act on hints that somebody will be doing sequential access, then it should be more timid about caching for that file access. That is to say, it should allow that file to "use up" a smaller number of blocks from the cache (yes, the VM) at a time, and it should favor, if anything, a LIFO scheme instead of the usual FIFO (LRU) scheme. (That is to say, for the special case of *sequential* access, LRU == FIFO, and yet LIFO is probably more optimal for this case, at least if the file will be re-read later.) Caching will do more good on files that that will be randomly accessed; an intermediate amount of good on files sequentially accessed but rewound and/or accessed over and over, and if the file system could somehow know (or be hinted) that the file is being sequentially accessed and is unlikely to be accessed again for a good long while it would clearly be better off not caching it at all. Of course the trick here is waving my hands and saying "assume that you know how the file will be accessed in the future." You ought to pillory me for *that* bit. Even with hinting there are problems with this whole idea. Still with some hinting the algorithm could probably be a little more clever. (Actually, Terry Lambert *did* pillory me for that bit, just a bit, when he pointed out the impossibility of knowing whether the file is being used in the same way by other processes.) And . . . also to Terry, yes, I know that my proposal about over-simplifies, but the point is that for sequential access you want to go "gentle" on making the cache of other process' and earlier reads go away. On Monday 27 January 2003 12:44 am, Tim Kientzle wrote: | Brian T. Schellenberger wrote: | > This to me is imminently sensible. | > In fact there seem like two rules that have come up in this | > discussion: | > | > 1. For sequential access, you should be very hesitant to throw away | > *another* processes blocks, at least once you have used more than, | > say, 25% of the cache or potential cache. | > | > 2. For sequential access, you should stop caching before you throw | > away your own blocks. If it's sequential it is, it seems to me, | > always a lose to throw away your *own* processes older bllocks on | > thee same file. | | The question isn't "should I throw away blocks or not?". | Obviously, the ideal is to keep everything in the cache, but | that's not possible. | | The question is "what blocks should be discarded?" You've | ruled out quite a few possibilities here. What blocks _should_ | be discarded? | | Tim Kientzle To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message