On Mon, 2012-12-17 at 13:12 -0500, Johannes Weiner wrote: > When ex-KSM pages are faulted from swap cache, the fault handler is > not capable of re-establishing anon_vma-spanning KSM pages. In this > case, a copy of the page is created instead, just like during a COW > break. > > These freshly made copies are known to be exclusive to the faulting > VMA and there is no reason to go look for this page in parent and > sibling processes during rmap operations. > > Use page_add_new_anon_rmap() for these copies. This also puts them on > the proper LRU lists and marks them SwapBacked, so we can get rid of > doing this ad-hoc in the KSM copy code.
Is it just a code cleanup instead of reduce rmap overhead? > > Signed-off-by: Johannes Weiner <han...@cmpxchg.org> > Reviewed-by: Rik van Riel <r...@redhat.com> > --- > mm/ksm.c | 6 ------ > mm/memory.c | 5 ++++- > 2 files changed, 4 insertions(+), 7 deletions(-) > > diff --git a/mm/ksm.c b/mm/ksm.c > index 382d930..7275c74 100644 > --- a/mm/ksm.c > +++ b/mm/ksm.c > @@ -1590,13 +1590,7 @@ struct page *ksm_does_need_to_copy(struct page *page, > > SetPageDirty(new_page); > __SetPageUptodate(new_page); > - SetPageSwapBacked(new_page); > __set_page_locked(new_page); > - > - if (!mlocked_vma_newpage(vma, new_page)) > - lru_cache_add_lru(new_page, LRU_ACTIVE_ANON); > - else > - add_page_to_unevictable_list(new_page); > } > > return new_page; > diff --git a/mm/memory.c b/mm/memory.c > index db2e9e7..7e17eb0 100644 > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -3020,7 +3020,10 @@ static int do_swap_page(struct mm_struct *mm, struct > vm_area_struct *vma, > } > flush_icache_page(vma, page); > set_pte_at(mm, address, page_table, pte); > - do_page_add_anon_rmap(page, vma, address, exclusive); > + if (swapcache) /* ksm created a completely new copy */ > + page_add_new_anon_rmap(page, vma, address); > + else > + do_page_add_anon_rmap(page, vma, address, exclusive); > /* It's better to call commit-charge after rmap is established */ > mem_cgroup_commit_charge_swapin(page, ptr); > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
