2.4.10 does not set accessed bit for readahead pages

Marcelo Tosatti (marcelo@conectiva.com.br)
Fri, 28 Sep 2001 15:24:28 -0300 (BRT)


Hi people,

I was taking a closer look at 2.4.10's mark_page_accessed() changes
(unfortunately just now, I've been quite busy lately with other issues)
and I noticed that readahead pages are not having their referenced bit set
when they are found in cache.

page_cache_read() (called by generic_file_readahead()), will simply do a
pagecache lookup and return in case the (being readahead) page is already
there.

I've done some experiments in the past trying to use a new GFP_ flag for
allocation of readahead pages. This new GFP flag was the indicator to
__alloc_pages() that it should fail very easily (so, in theory, we would
not spend time on page reclaiming for readahead, which is simply a guess).

With the above working, I got much slower results: It showed me in
practice, with real numbers, that the additional page reclaiming work for
readahead pages was worth due to the avoided disk seeks.

So I think it makes quite some sense to avoid readahead pages from being
removed from the cache easily, by calling mark_page_accessed() at
page_cache_read():

--- filemap.c.orig Fri Sep 28 16:43:57 2001
+++ filemap.c Fri Sep 28 16:44:56 2001
@@ -670,8 +670,10 @@
spin_lock(&pagecache_lock);
page = __find_page_nolock(mapping, offset, *hash);
spin_unlock(&pagecache_lock);
- if (page)
+ if (page) {
+ mark_page_accessed(page);
return 0;
+ }

page = page_cache_alloc(mapping);
if (!page)

NOTE: I'm saying that it is _bad_ to throw away readahead pages easily
because I've seen it in practice. I'll try to test this in real practice
again soon (not this week) to make sure.

Comments ?

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