Message-ID: <CAAa6QmTA8aADSYbpxXU8kne0KqyeY7fCw5_QYSj0T7bCtPKmfA@mail.gmail.com>
Date:   Wed, 16 Aug 2023 14:31:06 -0700
From:   "Zach O'Keefe" <zokeefe@...gle.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Saurabh Singh Sengar <ssengar@...rosoft.com>,
        Dan Williams <dan.j.williams@...el.com>,
        "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Yang Shi <shy828301@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [EXTERNAL] [PATCH] mm/thp: fix "mm: thp: kill __transhuge_page_enabled()"

On Mon, Aug 14, 2023 at 7:24 PM Matthew Wilcox <willy@...radead.org> wrote:
>
> On Mon, Aug 14, 2023 at 05:04:47PM -0700, Zach O'Keefe wrote:
> > > From a large folios perspective, filesystems do not implement a special
> > > handler.  They call filemap_fault() (directly or indirectly) from their
> > > ->fault handler.  If there is already a folio in the page cache which
> > > satisfies this fault, we insert it into the page tables (no matter what
> > > size it is).  If there is no folio, we call readahead to populate that
> > > index in the page cache, and probably some other indices around it.
> > > That's do_sync_mmap_readahead().
> > >
> > > If you look at that, you'll see that we check the VM_HUGEPAGE flag, and
> > > if set we align to a PMD boundary and read two PMD-size pages (so that we
> > > can do async readahead for the second page, if we're doing a linear scan).
> > > If the VM_HUGEPAGE flag isn't set, we'll use the readahead algorithm to
> > > decide how large the folio should be that we're reading into; if it's a
> > > random read workload, we'll stick to order-0 pages, but if we're getting
> > > good hit rate from the linear scan, we'll increase the size (although
> > > we won't go past PMD size)
> > >
> > > There's also the ->map_pages() optimisation which handles page faults
> > > locklessly, and will fail back to ->fault() if there's even a light
> > > breeze.  I don't think that's of any particular use in answering your
> > > question, so I'm not going into details about it.
> > >
> > > I'm not sure I understand the code that's being modified well enough to
> > > be able to give you a straight answer to your question, but hopefully
> > > this is helpful to you.
> >
> > Thank you, this was great info. I had thought, incorrectly, that large
> > folio work would eventually tie into that ->huge_fault() handler
> > (should be dax_huge_fault() ?)
> >
> > If that's the case, then faulting file-backed, non-DAX memory as
> > (pmd-mapped-)THPs isn't supported at all, and no fault lies with the
> > aforementioned patches.
>
> Ah, wait, hang on.  You absolutely can get a PMD mapping by calling into
> ->fault.  Look at how finish_fault() works:
>
>         if (pmd_none(*vmf->pmd)) {
>                 if (PageTransCompound(page)) {
>                         ret = do_set_pmd(vmf, page);
>                         if (ret != VM_FAULT_FALLBACK)
>                                 return ret;
>                 }
>
>                 if (vmf->prealloc_pte)
>                         pmd_install(vma->vm_mm, vmf->pmd, &vmf->prealloc_pte);
>
> So if we find a large folio that is PMD mappable, and there's nothing
> at vmf->pmd, we install a PMD-sized mapping at that spot.  If that
> fails, we install the preallocated PTE table at vmf->pmd and continue to
> trying set one or more PTEs to satisfy this page fault.

Aha! I see. I did not expect ->fault() to have this logic, as I had
incorrectly thought (aka assumed) the pmd vs pte-mapping logic split
at create_huge_pmd(); i.e. do_huge_pmd_anonymous_page(), or
->huge_fault(), or fallback to pte-mapping. It seems very weird to me
that hugepage_vma_check() "artificially" says "no" to file and shmem
along the fault path, so they can go and do their own thing in
->fault().

But this has been the way non-anon has supported THP fault since the
start ... with Kiril's commit 4.8 commit 101024596441 ("mm: introduce
do_set_pmd()") as part of the original "THP-enabled tmpfs/shmem using
compound pages" series. I just did not know about it :/

But thanks for prompting this -- I learnt a lot reading further down
do_fault(). shmem's ability to fault THP will depend on how the file
was constructed to begin with (i.e the huge= mount option). For file,
our ability to pmd-map the folio will depend on if the folio was
assembled in the pagecache as a large folio or not -- which depends on
the fs' AS_LARGE_FOLIO_SUPPORT (for which, only xfs, erofs, and afs
support today).

I tested things on xfs, and it does actually work. Cool :)

IIUC then, there is a bug in smaps THPeligible code when
CONFIG_READ_ONLY_THP_FOR_FS is not set. Not obvious, but apparently
this config is (according to it's Kconfig desc) khugepaged-only, so it
should be fine for it to be disabled, yet allow
do_sync_mmap_readahead() to install a pmd for file-backed memory.
hugepage_vma_check() will need to be patched to fix this.

But I have a larger question for you: should we care about
/sys/kernel/mm/transparent_hugepage/enabled for file-fault? We
currently don't. Seems weird that we can transparently get a hugepage
when THP="never". Also, if THP="always", we might as well skip the
VM_HUGEPAGE check, and try the final pmd install (and save khugepaged
the trouble of attempting it later).

WDYT?

Aside: should have brought this to Cabal meeting today, but hadn't
finished going through things

>
> So why, you may be asking, do we have ->huge_fault.  Well, you should
> ask the clown who did commit b96375f74a6d ... in fairness to me,
> finish_fault() did not exist at the time, and the ability to return
> a PMD-sized page was added later.
>

:P

But that patch seems super reasonable? At least my naive initial
reading assumed exactly what that commit description says.

Powered by blists - more mailing lists