Commit bf3f3bc5 authored Jan 06, 2009 by Nick Piggin Committed by Linus Torvalds Jan 06, 2009

mm: don't mark_page_accessed in fault path

Doing a mark_page_accessed at fault-time, then doing SetPageReferenced at
unmap-time if the pte is young has a number of problems.

mark_page_accessed is supposed to be roughly the equivalent of a young pte
for unmapped references. Unfortunately it doesn't come with any context:
after being called, reclaim doesn't know who or why the page was touched.

So calling mark_page_accessed not only adds extra lru or PG_referenced
manipulations for pages that are already going to have pte_young ptes anyway,
but it also adds these references which are difficult to work with from the
context of vma specific references (eg. MADV_SEQUENTIAL pte_young may not
wish to contribute to the page being referenced).

Then, simply doing SetPageReferenced when zapping a pte and finding it is
young, is not a really good solution either. SetPageReferenced does not
correctly promote the page to the active list for example. So after removing
mark_page_accessed from the fault path, several mmap()+touch+munmap() would
have a very different result from several read(2) calls for example, which
is not really desirable.

Signed-off-by: Nick Piggin <npiggin@suse.de>
Acked-by: Johannes Weiner <hannes@saeurebad.de>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

parent 3340289d

mm/filemap.c

+0 −1

Original line number	Diff line number	Diff line
		@@ -1530,7 +1530,6 @@ retry_find:
		/*
		* Found the page and have a reference on it.
		*/
		mark_page_accessed(page);
		ra->prev_pos = (loff_t)page->index << PAGE_CACHE_SHIFT;
		vmf->page = page;
		return ret \| VM_FAULT_LOCKED;

mm/memory.c

+1 −1

Original line number	Diff line number	Diff line
		@@ -768,7 +768,7 @@ static unsigned long zap_pte_range(struct mmu_gather *tlb,
		if (pte_dirty(ptent))
		set_page_dirty(page);
		if (pte_young(ptent))
		SetPageReferenced(page);
		mark_page_accessed(page);
		file_rss--;
		}
		page_remove_rmap(page, vma);

Admin message