Barry Song <21cnbao@xxxxxxxxx> writes: > On Mon, Apr 8, 2024 at 7:20 PM Huang, Ying <ying.huang@xxxxxxxxx> wrote: >> >> Barry Song <21cnbao@xxxxxxxxx> writes: >> >> > From: Chuanhua Han <hanchuanhua@xxxxxxxx> >> > >> > When a large folio is found in the swapcache, the current implementation >> > requires calling do_swap_page() nr_pages times, resulting in nr_pages >> > page faults. This patch opts to map the entire large folio at once to >> > minimize page faults. Additionally, redundant checks and early exits >> > for ARM64 MTE restoring are removed. >> >> For large folios in reclaiming, it makes sense to restore all PTE >> mappings to the large folio to reduce the number of page faults. >> > > Indeed, this patch addresses the refault case first, much less controversial > then :-) > >> But for large folios swapped in, I think that it's better to map one PTE >> which triggers the page fault only. Because this makes us get the >> opportunity to trap the page accesses to the sub-pages of the large >> folio that is swapped in ahead (kind of swap readahead). Then we can >> decide the order of large folio swapin based on the readahead window >> information. That is, we may need to check PageReadahead() to decide >> whether to map all PTEs in the future. > > Another scenario occurs when a process opts to utilize large folios for > swap_readahead. Subsequently, another process encounters the large > folios introduced by the former process. In this case, would it be optimal > to fully map them just like the refault case? We only need to trap the first access to the readahead sub-page. So, we can map PTE for all sub-pages without PageReadahead(). IIUC, now readahead flag is per-folio, we may need to change it to per-sub-page when needed. -- Best Regards, Huang, Ying
