linux-kernel - [PATCH 0/2] mm: rmap: merge HugeTLB mapcount logic with THPs

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-next>] [day] [month] [year] [list]

Message-ID: <20230306230004.1387007-1-jthoughton@google.com>
Date:   Mon,  6 Mar 2023 23:00:02 +0000
From:   James Houghton <jthoughton@...gle.com>
To:     Mike Kravetz <mike.kravetz@...cle.com>,
        Hugh Dickins <hughd@...gle.com>,
        Muchun Song <songmuchun@...edance.com>,
        Peter Xu <peterx@...hat.com>,
        "Matthew Wilcox (Oracle)" <willy@...radead.org>,
        Andrew Morton <akpm@...ux-foundation.org>
Cc:     "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
        David Hildenbrand <david@...hat.com>,
        David Rientjes <rientjes@...gle.com>,
        Axel Rasmussen <axelrasmussen@...gle.com>,
        Jiaqi Yan <jiaqiyan@...gle.com>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org,
        James Houghton <jthoughton@...gle.com>
Subject: [PATCH 0/2] mm: rmap: merge HugeTLB mapcount logic with THPs

HugeTLB pages may soon support being mapped with PTEs. To allow for this
case, merge HugeTLB's mapcount scheme with THP's.

The first patch of this series comes from the HugeTLB high-granularity
mapping series[1], though with some updates, as the original version
was buggy[2] and incomplete.

I am sending this change as part of this smaller series in hopes that it
can be more thoroughly scrutinized.

I haven't run any THP performance tests with this series applied.
HugeTLB pages don't currently support being mapped with
`compound=false`, but this mapcount scheme will make collapsing
compound=false mappings in HugeTLB pages quite slow. This can be
optimized with future patches (likely by taking advantage of HugeTLB's
alignment guarantees).

Matthew Wilcox is working on a mapcounting scheme[3] that will avoid
the use of each subpage's mapcount. If this series is applied, Matthew's
new scheme will automatically apply to HugeTLB pages.

[1]: https://lore.kernel.org/linux-mm/20230218002819.1486479-6-jthoughton@google.com/
[2]: https://lore.kernel.org/linux-mm/CACw3F538H+bYcvSY-qG4-gmrgGPRBgTScDzrX9suLyp_q+v_bQ@mail.gmail.com/
[3]: https://lore.kernel.org/linux-mm/Y9Afwds%2FJl39UjEp@casper.infradead.org/

James Houghton (2):
  mm: rmap: make hugetlb pages participate in _nr_pages_mapped
  mm: rmap: increase COMPOUND_MAPPED to support 512G HugeTLB pages

 include/linux/mm.h |  7 +------
 mm/hugetlb.c       |  4 ++--
 mm/internal.h      |  9 ++++-----
 mm/migrate.c       |  2 +-
 mm/rmap.c          | 35 ++++++++++++++++++++---------------
 5 files changed, 28 insertions(+), 29 deletions(-)

base-commit: 9caa15b8a49949342bdf495bd47660267a3bd371
-- 
2.40.0.rc0.216.gc4246ad0f0-goog