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

[Daeho Jeong]

On Wed, Sep 9, 2026 at 12:37 AM Chao Yu via Linux-f2fs-devel
<linux-f2fs-devel@xxxxxxxxxxxxxxxxxxxxx> wrote:
>
> 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?
>

Hi Chao, Nanzhe,

I agree with Chao. The write amplification caused by batch-installing
writable PTEs in finish_fault() is indeed severe for flash storage - a
single 4KB store can easily amplify to 64KB (16x) or 2MB (512x) of
disk writes.

Here is my suggestion for our short-term and long-term plan:

Short-term:

Clamp max folio order: Restrict the maximum folio order for writable
files. This caps the worst-case write amplification while still
preserving batching and ContPTE benefits.
Selective split_folio(): If we want to allow higher orders (e.g. >
16KB) for pure buffered I/O, we can conditionally call split_folio()
in f2fs_vm_page_mkwrite() to fall back to order-0 upon shared mmap
write faults.
Long-term: The fundamental solution belongs in mm. I think the CPU MMU
already tracks dirty states per-PTE.
Once the ongoing mm proposals for PTE dirty harvesting land in
mainline, F2FS can simply query which subpages were actually dirtied
at writeback time rather than prematurely dirtying the whole folio in
page_mkwrite().

Until mm gains subpage dirty tracking for mmap, clamping the folio
order (and optionally splitting high orders on write fault) is the
most practical way forward.

Thanks,
Daeho

> Thanks,
>
> >
> > Thanks,
> > Nanzhe
>
>
>
> _______________________________________________
> Linux-f2fs-devel mailing list
> Linux-f2fs-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel