linux-kernel - Re: [PATCH v5 3/5] mm: LARGE_ANON

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAHbLzkpQ-qzFpc0nntoodRMunTtgRKHQCfV8ubXwQQeVVNo+uw@mail.gmail.com>
Date:   Fri, 1 Sep 2023 10:18:54 -0700
From:   Yang Shi <shy828301@...il.com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     David Hildenbrand <david@...hat.com>,
        "Huang, Ying" <ying.huang@...el.com>,
        Ryan Roberts <ryan.roberts@....com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Yin Fengwei <fengwei.yin@...el.com>,
        Yu Zhao <yuzhao@...gle.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Zi Yan <ziy@...dia.com>, Luis Chamberlain <mcgrof@...nel.org>,
        Itaru Kitayama <itaru.kitayama@...il.com>,
        "Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH v5 3/5] mm: LARGE_ANON_FOLIO for improved performance

On Fri, Sep 1, 2023 at 9:13 AM Matthew Wilcox <willy@...radead.org> wrote:
>
> On Thu, Aug 31, 2023 at 10:15:09AM -0700, Yang Shi wrote:
> > On Thu, Aug 31, 2023 at 12:57 AM David Hildenbrand <david@...hat.com> wrote:
> > > Let's talk about that in a bi-weekly MM session. (I proposed it as a
> > > topic for next week).
> > >
> > > As raised in another mail, we can then discuss
> > > * how we want to call this feature (transparent large pages? there is
> > >    the concern that "THP" might confuse users. Maybe we can consider
> > >    "large" the more generic version and "huge" only PMD-size, TBD)
> >
> > I tend to agree. "Huge" means PMD-mappable (transparent or HugeTLB),
> > "Large" means any order but less than PMD-mappable order, "Gigantic"
> > means PUD mappable. This should incur the least confusion IMHO.
>
> "Large" means any order > 0.  The limitation to <= PMD_ORDER is simply
> because I don't want to go through the whole VM and fix all the places
> that assume that pmd_page() returns a head page.  The benefit to doing so
> is quite small, and the work to achieve it is quite large.  The amount of
> work needed should decrease over time as we convert more code to folios,
> so deferring it is the right decision today.

Yeah, I agree. And we are on the same page.

>
> But nobody should have the impression that large folios are smaller
> than PMD size, nor even less than or equal.  Just like they shouldn't
> think that large folios depend on CONFIG_TRANSPARENT_HUGEPAGE.  They do
> today, but that's purely an implementation detail that will be removed
> eventually.

Yes, THP should be just a special case of large folio from page table
point of view (for example, PMD-mappable vs non-PMD-mappable).

>
> > > I think there *really* has to be a way to disable it for a running
> > > system, otherwise no distro will dare pulling it in, even after we
> > > figured out the other stuff.
> >
> > TBH I really don't like to tie large folio to THP toggles. THP
> > (PMD-mappable) is just a special case of LAF. The large folio should
> > be tried whenever it is possible ideally. But I do agree we may not be
> > able to achieve the ideal case at the time being, and also understand
> > the concern about regression in early adoption, so a knob that can
> > disable large folio may be needed for now. But it should be just a
> > simple binary knob (on/off), and should not be a part of kernel ABI
> > (temporary and debugging only) IMHO.
>
> Best of luck trying to remove it after you've shipped it ... we've
> never been able to remove any of the THP toggles, only make them more
> complicated.

Fingers crossed... and my point is we should try to avoid making
things more complicated. It may be hard...

>
> > One more thing we may discuss is whether huge page madvise APIs should
> > take effect for large folio or not.
>
> They already do for file large folios; we listen to MADV_HUGEPAGE and
> attempt to allocate PMD_ORDER folios for faults.

OK, file folio may be simpler than anonymous. For anonymous folio,
there may be two potential cases depending on our choice:

Tie large folio to THP knobs:
MADV_HUGEPAGE - large folio if THP is on/no large folio if THP is off
MADV_NOHUGEPAGE - no large folio

Not tie large folio to THP knob:
MADV_HUGEPAGE - always large folio
MADV_NOHUGEPAGE - shall create large folio?

>