On 1/30/2023 8:54 PM, Yin Fengwei wrote: > Current filemap_map_pages() still use page granularity > even when the underneath folio is large folio. Making it > use folio based granularity allows batched refcount, > rmap and mm counter opertion. Which brings some level > performance gain. This series tries to update > filemap_map_pages() > do_set_pte() > page_add_file_rmap() > to bring batched refcount, rmap and mm counter in. > > Patch 1 enabled the fault around for shared file page > write fault. As David suggested here: > https://lore.kernel.org/linux-mm/e14b4e9a-612d-fc02-edc0-8f3b6bcf4148@xxxxxxxxxx/ > > Patch 2 update filemap_map_pages() to do map based on > folio granularity and batched refcount update > > Patch 3,4,5 Enable batched rmap and mm counter > > Function testing: > - two days daily usage: boot to xfs GUI, kernel build, editor and browser > > Performance testing: > - kernel build: no obvious performance impact > - micro benchmark: will-it-scale:page_fault3 (shared file write fault) > Patch 1 brings 3.75X performance gain > > - micro benchmark: will-it-scale:page_fault3 like but with file read fault > - Patch 2 brings about 2% performance gain (batched refcount) > - Patch 3,4,5 brings about 15% performance gain (batched rmap and mm counter) > Forgot to mention: the base of the series is next-20230119. > > Yin Fengwei (5): > mm: Enable fault around for shared file page fault > filemap: do file page mapping with folio granularity > rmap: add page_add_file_rmap_range() > mm: add do_set_pte_entry() > filemap: batched update mm counter,rmap when map file folio > > include/linux/mm.h | 2 + > include/linux/rmap.h | 2 + > mm/filemap.c | 106 +++++++++++++++++++++++++++++-------------- > mm/memory.c | 25 +++++++++- > mm/rmap.c | 70 +++++++++++++++++----------- > 5 files changed, 143 insertions(+), 62 deletions(-) >
