lkml.org 
[lkml]   [2001]   [Sep]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: linux-2.4.10-pre5


--On Tuesday, 11 September, 2001 1:13 AM +0200 Daniel Phillips
<phillips@bonn-fries.net> wrote:

> OK, now to shorten this up, if you've reached the conclusion that the
> page cache needs to be able to take advantage of blocks already read
> into the buffer cache then we're done. That was my point all along.

ACK. May be I am arguing all pages read should live in page/unified cache,
i.e. current buffer cache should at most contain references to data already
read and influence expiry of those pages (as opposed to hold private copies
thereof) - see previous readahead debate ref best/worst pages to expire -
BUT STILL thus drive what is cached at the layers below, (i.e.
drive the file based readahead). Not saying there is necessarilly no place
for physical readahead even with disks being able to do it, just difficult
to measure whilst all logical readahead pages put in buffer cache cannot be
taken advantage of by page cache.

It may well be that I am lagging well behind on the thought process.
Need lkml readahead obviously :-)

--
Alex Bligh
-
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/

\
 
 \ /
  Last update: 2005-03-22 13:03    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site