Re: [f2fs-dev] [PATCH 06/14] f2fs: prepare mmap write faults for large folios

[Chao Yu]

On 9/7/26 15:34, Nanzhe Zhao wrote:
> On Thu, 27 Aug 2026 20:36:02 +0800, Chao Yu wrote:
>> We only need to call f2fs_get_block_locked() for vmf->page?
>>
>> Hi Barry, could you please help to confirm this? Only vmf->page contain dirty
>> data, rather than whole large folio contain dirty data?
> 
> Thanks for the review. Here is the write-fault path on current
> mainline (mm/memory.c):
> 
> do_pte_missing()                          memory.c:4561
>   -> do_fault()                           memory.c:5964
>     -> do_shared_fault()                  memory.c:5914
>       -> __do_fault() -> filemap_fault()  : fault in folio (may be 16KB)
>       -> do_page_mkwrite(vmf, folio)      : page_mkwrite ONCE per folio (memory.c:5936)
>          -> vma->vm_ops->page_mkwrite(vmf)  memory.c:3684
>       -> finish_fault()                   memory.c:5617
>          -> set_pte_range()               memory.c:5558
>             if (write)
>                 entry = maybe_mkwrite(pte_mkdirty(entry), vma);   memory.c:5575
>             set_ptes(vma->vm_mm, addr, vmf->pte, entry, nr);      memory.c:5586
> 
> So page_mkwrite is entered once per folio, and afterwards the PTEs of
> all subpages are installed writable in one go - writes to other
> subpages of the same folio will not fault again. That is why
> f2fs_vm_page_mkwrite() preallocates/marks dirty_len rather than
> handling vmf->page only.
> 
> I'll add a comment in f2fs_vm_page_mkwrite() in the next version to
> make the point clear.

I see, we'd better limit the upper boundary of folio order in order to avoid
large write amplification, since even user only write 4k page via mmap, it will
dirty entire large folio, IIUC.

To Jaegeuk, Daeho, any comments?

Thanks,

> 
> Thanks,
> Nanzhe