Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
MIME-Version: 1.0
References: <20230726095146.2826796-1-ryan.roberts@arm.com>
 <20230726095146.2826796-3-ryan.roberts@arm.com> <c02a95e9-b728-ad64-6942-f23dbd66af0c@arm.com>
In-Reply-To: <c02a95e9-b728-ad64-6942-f23dbd66af0c@arm.com>
From:   Yu Zhao <yuzhao@google.com>
Date:   Thu, 3 Aug 2023 17:50:38 -0600
Message-ID: <CAOUHufaHH3Ctu3JRHSbmebHJ7XPnBEWTQ4mwOo+MGXU9yKvwbA@mail.gmail.com>
Subject: Re: [PATCH v4 2/5] mm: LARGE_ANON_FOLIO for improved performance
To:     Ryan Roberts <ryan.roberts@arm.com>
Cc:     Andrew Morton <akpm@linux-foundation.org>,
        Matthew Wilcox <willy@infradead.org>,
        Yin Fengwei <fengwei.yin@intel.com>,
        David Hildenbrand <david@redhat.com>,
        Catalin Marinas <catalin.marinas@arm.com>,
        Will Deacon <will@kernel.org>,
        Anshuman Khandual <anshuman.khandual@arm.com>,
        Yang Shi <shy828301@gmail.com>,
        "Huang, Ying" <ying.huang@intel.com>, Zi Yan <ziy@nvidia.com>,
        Luis Chamberlain <mcgrof@kernel.org>,
        Itaru Kitayama <itaru.kitayama@gmail.com>,
        "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>,
        linux-mm@kvack.org, linux-kernel@vger.kernel.org,
        linux-arm-kernel@lists.infradead.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On Thu, Aug 3, 2023 at 6:43=E2=80=AFAM Ryan Roberts <ryan.roberts@arm.com> =
wrote:
>
> + Kirill
>
> On 26/07/2023 10:51, Ryan Roberts wrote:
> > Introduce LARGE_ANON_FOLIO feature, which allows anonymous memory to be
> > allocated in large folios of a determined order. All pages of the large
> > folio are pte-mapped during the same page fault, significantly reducing
> > the number of page faults. The number of per-page operations (e.g. ref
> > counting, rmap management lru list management) are also significantly
> > reduced since those ops now become per-folio.
> >
> > The new behaviour is hidden behind the new LARGE_ANON_FOLIO Kconfig,
> > which defaults to disabled for now; The long term aim is for this to
> > defaut to enabled, but there are some risks around internal
> > fragmentation that need to be better understood first.
> >
> > When enabled, the folio order is determined as such: For a vma, process
> > or system that has explicitly disabled THP, we continue to allocate
> > order-0. THP is most likely disabled to avoid any possible internal
> > fragmentation so we honour that request.
> >
> > Otherwise, the return value of arch_wants_pte_order() is used. For vmas
> > that have not explicitly opted-in to use transparent hugepages (e.g.
> > where thp=3Dmadvise and the vma does not have MADV_HUGEPAGE), then
> > arch_wants_pte_order() is limited to 64K (or PAGE_SIZE, whichever is
> > bigger). This allows for a performance boost without requiring any
> > explicit opt-in from the workload while limitting internal
> > fragmentation.
> >
> > If the preferred order can't be used (e.g. because the folio would
> > breach the bounds of the vma, or because ptes in the region are already
> > mapped) then we fall back to a suitable lower order; first
> > PAGE_ALLOC_COSTLY_ORDER, then order-0.
> >
>
> ...
>
> > +#define ANON_FOLIO_MAX_ORDER_UNHINTED \
> > +             (ilog2(max_t(unsigned long, SZ_64K, PAGE_SIZE)) - PAGE_SH=
IFT)
> > +
> > +static int anon_folio_order(struct vm_area_struct *vma)
> > +{
> > +     int order;
> > +
> > +     /*
> > +      * If THP is explicitly disabled for either the vma, the process =
or the
> > +      * system, then this is very likely intended to limit internal
> > +      * fragmentation; in this case, don't attempt to allocate a large
> > +      * anonymous folio.
> > +      *
> > +      * Else, if the vma is eligible for thp, allocate a large folio o=
f the
> > +      * size preferred by the arch. Or if the arch requested a very sm=
all
> > +      * size or didn't request a size, then use PAGE_ALLOC_COSTLY_ORDE=
R,
> > +      * which still meets the arch's requirements but means we still t=
ake
> > +      * advantage of SW optimizations (e.g. fewer page faults).
> > +      *
> > +      * Finally if thp is enabled but the vma isn't eligible, take the
> > +      * arch-preferred size and limit it to ANON_FOLIO_MAX_ORDER_UNHIN=
TED.
> > +      * This ensures workloads that have not explicitly opted-in take =
benefit
> > +      * while capping the potential for internal fragmentation.
> > +      */
> > +
> > +     if ((vma->vm_flags & VM_NOHUGEPAGE) ||
> > +         test_bit(MMF_DISABLE_THP, &vma->vm_mm->flags) ||
> > +         !hugepage_flags_enabled())
> > +             order =3D 0;
> > +     else {
> > +             order =3D max(arch_wants_pte_order(), PAGE_ALLOC_COSTLY_O=
RDER);
> > +
> > +             if (!hugepage_vma_check(vma, vma->vm_flags, false, true, =
true))
> > +                     order =3D min(order, ANON_FOLIO_MAX_ORDER_UNHINTE=
D);
> > +     }
> > +
> > +     return order;
> > +}
>
>
> Hi All,
>
> I'm writing up the conclusions that we arrived at during discussion in th=
e THP
> meeting yesterday, regarding linkage with exiting THP ABIs. It would be g=
reat if
> I can get explicit "agree" or disagree + rationale from at least David, Y=
u and
> Kirill.
>
> In summary; I think we are converging on the approach that is already cod=
ed, but
> I'd like confirmation.
>
>
>
> The THP situation today
> -----------------------
>
>  - At system level: THP can be set to "never", "madvise" or "always"
>  - At process level: THP can be "never" or "defer to system setting"
>  - At VMA level: no-hint, MADV_HUGEPAGE, MADV_NOHUGEPAGE
>
> That gives us this table to describe how a page fault is handled, accordi=
ng to
> process state (columns) and vma flags (rows):
>
>                 | never     | madvise   | always
> ----------------|-----------|-----------|-----------
> no hint         | S         | S         | THP>S
> MADV_HUGEPAGE   | S         | THP>S     | THP>S
> MADV_NOHUGEPAGE | S         | S         | S
>
> Legend:
> S       allocate single page (PTE-mapped)
> LAF     allocate lage anon folio (PTE-mapped)
> THP     allocate THP-sized folio (PMD-mapped)
> >       fallback (usually because vma size/alignment insufficient for fol=
io)
>
>
>
> Principles for Large Anon Folios (LAF)
> --------------------------------------
>
> David tells us there are use cases today (e.g. qemu live migration) which=
 use
> MADV_NOHUGEPAGE to mean "don't fill any PTEs that are not explicitly faul=
ted"
> and these use cases will break (i.e. functionally incorrect) if this requ=
est is
> not honoured.

I don't remember David saying this. I think he was referring to UFFD,
not MADV_NOHUGEPAGE, when discussing what we need to absolutely
respect.