linux-kernel - Re: [RESEND PATCH v7 00/10] Small-sized THP for anonymous memory

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: <f8e518f2-fb15-4295-a335-bea5a8010ab2@arm.com>
Date:   Fri, 24 Nov 2023 09:56:37 +0000
From:   Ryan Roberts <ryan.roberts@....com>
To:     Matthew Wilcox <willy@...radead.org>
Cc:     Andrew Morton <akpm@...ux-foundation.org>,
        Yin Fengwei <fengwei.yin@...el.com>,
        David Hildenbrand <david@...hat.com>,
        Yu Zhao <yuzhao@...gle.com>,
        Catalin Marinas <catalin.marinas@....com>,
        Anshuman Khandual <anshuman.khandual@....com>,
        Yang Shi <shy828301@...il.com>,
        "Huang, Ying" <ying.huang@...el.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>,
        John Hubbard <jhubbard@...dia.com>,
        David Rientjes <rientjes@...gle.com>,
        Vlastimil Babka <vbabka@...e.cz>,
        Hugh Dickins <hughd@...gle.com>,
        Kefeng Wang <wangkefeng.wang@...wei.com>, linux-mm@...ck.org,
        linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [RESEND PATCH v7 00/10] Small-sized THP for anonymous memory

On 23/11/2023 15:59, Matthew Wilcox wrote:
> On Wed, Nov 22, 2023 at 04:29:40PM +0000, Ryan Roberts wrote:
>> Note: I'm resending this at Andrew's suggestion due to having originally sent
>> it during LPC. I'm hoping its in a position where the feedback is minor enough
>> that I can rework in time for v6.8, but so far haven't had any.
>>
>> Hi All,
>>
>> This is v7 of a series to implement small-sized THP for anonymous memory
>> (previously called "large anonymous folios"). The objective of this is to
> 
> I'm still against small-sized THP.  We've now got people asking whether
> the THP counters should be updated when dealing with large folios that
> are smaller than PMD sized.  It's sowing confusion, and we should go
> back to large anon folios as a name.

I suspect I'm labouring the point here, but I'd like to drill into exactly what
you are objecting to. Is it:

A) Using the name "small-sized THP" (which is currently only used in the commit
logs and a couple of times in the documentation).

B) Exposing the controls for this feature as an extension to the existing
/sys/kernel/mm/transparent_hugepage/* sysfs interface (note the interface never
uses the term "small-sized").

If A) then this is easily solved by choosing another descriptive name and
updating those places. Personally I think it would be best to continue to use
"THP" since we are exposing the feature through that interface. Perhaps "large
folio THP".

If B) we could move the interface to /sys/kernel/mm/large_folio/*, but that
introduces many more banana skins than the current approach IMHO:

  - We would still want to expose the PMD-size large folio through this new
    interface and so would still need "global" or equivalent for at least PMD
    size, but "global" now points to a completely different sibling directory
    structure. And it probably doesn't make any sense for the non-PMD-sizes to
    have "global" because that would imply the THP interface could control the
    non-PMD-sizes, which is what we are trying to separate in the first place.
    So we end up with an asymmetry.

  - When we get to adding other feature support for the smaller sizes (e.g.
    khugepaged), we will end up having to duplicate all the controls from
    transparent_hugepage/* to large_folio/*, then we have the problem that e.g.
    scan rates could differ and we would end up needing 2 separate daemons.

On the interface, David and I did request feedback on the proposal a number of
times before I coded it up.

I'm sure all solvable eventually, but I personally think it is overall simpler
and more understandable as it is. I also agree with the other points raised in
favor of "small-sized THP".

Thanks,
Ryan