Date: Sun, 4 Jan 2004 15:32:58 -0800
From: Andrew Morton <akpm@osdl.org>
To: Mike Fedyk <mfedyk@matchmail.com>
Cc: ornati@lycos.it, gandalf@wlug.westbo.se, linuxram@us.ibm.com,
       linux-kernel@vger.kernel.org
Subject: Re: Buffer and Page cache coherent? was: Strange IDE performance
 change in 2.6.1-rc1 (again)
Message-Id: <20040104153258.0408a197.akpm@osdl.org>
In-Reply-To: <20040104232231.GV1882@matchmail.com>
References: <200401021658.41384.ornati@lycos.it>
	<20040102213228.GH1882@matchmail.com>
	<1073082842.824.5.camel@tux.rsn.bth.se>
	<200401031213.01353.ornati@lycos.it>
	<20040103144003.07cc10d9.akpm@osdl.org>
	<20040104171545.GR1882@matchmail.com>
	<20040104141030.02fbcce5.akpm@osdl.org>
	<20040104232231.GV1882@matchmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1832
Lines: 41

Mike Fedyk <mfedyk@matchmail.com> wrote:
>
> On Sun, Jan 04, 2004 at 02:10:30PM -0800, Andrew Morton wrote:
> > Mike Fedyk <mfedyk@matchmail.com> wrote:
> > >
> > > On Sat, Jan 03, 2004 at 02:40:03PM -0800, Andrew Morton wrote:
> > > > No effort was made to optimise buffered blockdev reads because it is not
> > > > very important and my main interest was in data coherency and filesystem
> > > > metadata consistency.
> > > 
> > > Does that mean that blockdev reads will populate the pagecache in 2.6?
> > 
> > They have since 2.4.10.  The pagecache is the only cacheing entity for file
> > (and blockdev) data.
> 
> There was a large thread after 2.4.10 was released about speeding up the
> boot proces by reading the underlying blockdev of the root partition in
> block order.
> 
> Unfortunately at the time reading the files through the pagecache would
> cause a second read of the data even if it was already buffered.  I don't
> remember the exact details.

The pagecache is a cache-per-inode.  So the cache for a regular file is not
coherent with the cache for /dev/hda1 is not coherent with the cache for
/dev/hda.

> Are you saying this is now resolved?  And the above optimization will work?

It will not.  And I doubt if it will make much difference anyway.  I once
wrote a gizmo which a) generated tables describing pagecache contents
immediately after bootup and b) used that info to prepopulate pagecache
with an optimised seek pattern after boot.  It was only worth 10-15%.  One
would need an intermediate step which relaid-out the relevant files to get
useful speedups.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/