Messages in this thread Patch in this message |  | | Date | Fri, 28 Sep 2001 15:24:28 -0300 (BRT) | From | Marcelo Tosatti <> | Subject | 2.4.10 does not set accessed bit for readahead pages |
| |
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/
|  |