From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Mon, 10 Sep 2001 20:05:56 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Mon, 10 Sep 2001 20:05:46 -0400 Received: from humbolt.nl.linux.org ([131.211.28.48]:35089 "EHLO humbolt.nl.linux.org") by vger.kernel.org with ESMTP id ; Mon, 10 Sep 2001 20:05:33 -0400 Content-Type: text/plain; charset=US-ASCII From: Daniel Phillips To: Linus Torvalds Subject: Re: linux-2.4.10-pre5 Date: Tue, 11 Sep 2001 01:20:50 +0200 X-Mailer: KMail [version 1.3.1] Cc: Andreas Dilger , Andrea Arcangeli , Kernel Mailing List In-Reply-To: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 7BIT Message-Id: <20010911000547Z16588-26185+142@humbolt.nl.linux.org> Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On September 11, 2001 12:15 am, Linus Torvalds wrote: > However, physical read-ahead really isn't the answer here. I bet you could > cut your time down with it, agreed. But you'd hurt a lot of other loads, > and it really depends on nice layout on disk. Plus you wouldn't even know > where to put the data you read-ahead: you only have the physical address, > not the logical address, and the page-cache is purely logically indexed.. You leave it in the buffer cache and the page cache checks for it there before deciding it has to hit the disk. For coherency, getblk has to check for the block in the page cache. We can this implement using the buffer hash chain links, currently unused for page cache buffers. -- Daniel