Re: [PATCH] mm, hugetlb: remove HUGETLB_CGROUP_MIN_ORDER

[Frank van der Linden <fvdl@google.com>]

On Thu, Oct 5, 2023 at 5:53 PM Mike Kravetz <mike.kravetz@oracle.com> wrote:
>
> On 10/04/23 15:32, Frank van der Linden wrote:
> > Originally, hugetlb_cgroup was the only hugetlb user of tail page
> > structure fields. So, the code defined and checked against
> > HUGETLB_CGROUP_MIN_ORDER to make sure pages weren't too small
> > to use.
> >
> > However, by now, tail page #2 is used to store hugetlb
> > hwpoison and subpool information as well. In other words,
> > without that tail page hugetlb doesn't work.
>
> When I first read this, I thought we might be exposed today.  But, I see
> that currently order must be > 0 so we are covered.
>
> > Acknowledge this fact by getting rid of HUGETLB_CGROUP_MIN_ORDER
> > and checks against it. Instead, just check for the minimum viable
> > page order at hstate creation time.
>
> IIUC, we do lose the ability to run with an order 1 hstate.  Correct?
> The minimum must now be 2.
> I do not think is worth worrying about.  And, the code checking for the
> VERY unlikely case where order could be big enough to to be valid, but
> too small for cgroups was strange.


Theoretically, order 1 hstate (without hugetlb cgroup) used to be
possible, since the subpool pointer was in the 1st tail page. But
dad6a5eb55 ("mm,hugetlb: use folio fields in second tail page")  moved
everything to fields in the 2nd tail page, so that hasn't worked for a
bit. I guess it would have let you create it, but things would have
gone south pretty quickly..
>
>
> I think this is a nice simplification.


Thanks for the review,

- Frank