On Wed, Jun 30, 2021 at 6:47 PM Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> wrote:
>
> From: Muchun Song <songmuchun@xxxxxxxxxxxxx>
> Subject: mm: hugetlb: free the vmemmap pages associated with each HugeTLB page
>
> Every HugeTLB has more than one struct page structure. We __know__ that
> we only use the first 4 (__NR_USED_SUBPAGE) struct page structures to
> store metadata associated with each HugeTLB.
>
> There are a lot of struct page structures associated with each HugeTLB
> page. For tail pages, the value of compound_head is the same. So we can
> reuse first page of tail page structures. [..]
I think this means to say that we can reuse the _second_ page of the
tail page structures, since the first page is special and also
contains the first (non-tail) 'struct page'.
Or maybe the intent is to say that that second page is the "first page
of purely tail page structures"?
Anyway, this HugeTLB 'struct page' vmemmap patch-series doesn't look
_wrong_ to me, but it does look like it is a nightmare to debug if
something ever goes wrong. And it looks like a lot of things _could_
go wrong. It all looks very subtle.
Put another way: I'm not objecting to this series, but it does make me
nervous, and I just want to give a heads-up that if we start seeing
problems with this, I think people need to be ready to very
aggressively revert it unless the fixes are obvious.
How much testing has this series gotten on loads that are heavy users
of hugetlb?
Linus
