linux-kernel - Re: [PATCH v3 00/12] mm/gup: Unify hugetlb, part 2

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]

Date: Mon, 25 Mar 2024 14:56:41 +0000
From: Christophe Leroy <christophe.leroy@...roup.eu>
To: "peterx@...hat.com" <peterx@...hat.com>, "linux-mm@...ck.org"
	<linux-mm@...ck.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>
CC: "linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>, Michael
 Ellerman <mpe@...erman.id.au>, Matthew Wilcox <willy@...radead.org>, Rik van
 Riel <riel@...riel.com>, Lorenzo Stoakes <lstoakes@...il.com>, Axel Rasmussen
	<axelrasmussen@...gle.com>, Yang Shi <shy828301@...il.com>, John Hubbard
	<jhubbard@...dia.com>, "linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "Kirill A . Shutemov"
	<kirill@...temov.name>, Andrew Jones <andrew.jones@...ux.dev>, Vlastimil
 Babka <vbabka@...e.cz>, Mike Rapoport <rppt@...nel.org>, Andrew Morton
	<akpm@...ux-foundation.org>, Muchun Song <muchun.song@...ux.dev>, Christoph
 Hellwig <hch@...radead.org>, "linux-riscv@...ts.infradead.org"
	<linux-riscv@...ts.infradead.org>, James Houghton <jthoughton@...gle.com>,
	David Hildenbrand <david@...hat.com>, Jason Gunthorpe <jgg@...dia.com>,
	Andrea Arcangeli <aarcange@...hat.com>, "Aneesh Kumar K . V"
	<aneesh.kumar@...nel.org>, Mike Kravetz <mike.kravetz@...cle.com>
Subject: Re: [PATCH v3 00/12] mm/gup: Unify hugetlb, part 2



Le 21/03/2024 à 23:07, peterx@...hat.com a écrit :
> From: Peter Xu <peterx@...hat.com>
> 
> v3:
> - Rebased to latest mm-unstalbe (a824831a082f, of March 21th)
> - Dropped patch to introduce pmd_thp_or_huge(), replace such uses (and also
>    pXd_huge() users) with pXd_leaf() [Jason]
> - Add a comment for CONFIG_PGTABLE_HAS_HUGE_LEAVES [Jason]
> - Use IS_ENABLED() in follow_huge_pud() [Jason]
> - Remove redundant none pud check in follow_pud_mask() [Jason]
> 
> rfc: https://lore.kernel.org/r/20231116012908.392077-1-peterx@redhat.com
> v1:  https://lore.kernel.org/r/20231219075538.414708-1-peterx@redhat.com
> v2:  https://lore.kernel.org/r/20240103091423.400294-1-peterx@redhat.com
> 
> The series removes the hugetlb slow gup path after a previous refactor work
> [1], so that slow gup now uses the exact same path to process all kinds of
> memory including hugetlb.
> 
> For the long term, we may want to remove most, if not all, call sites of
> huge_pte_offset().  It'll be ideal if that API can be completely dropped
> from arch hugetlb API.  This series is one small step towards merging
> hugetlb specific codes into generic mm paths.  From that POV, this series
> removes one reference to huge_pte_offset() out of many others.
> 
> One goal of such a route is that we can reconsider merging hugetlb features
> like High Granularity Mapping (HGM).  It was not accepted in the past
> because it may add lots of hugetlb specific codes and make the mm code even
> harder to maintain.  With a merged codeset, features like HGM can hopefully
> share some code with THP, legacy (PMD+) or modern (continuous PTEs).
> 
> To make it work, the generic slow gup code will need to at least understand
> hugepd, which is already done like so in fast-gup.  Due to the specialty of
> hugepd to be software-only solution (no hardware recognizes the hugepd
> format, so it's purely artificial structures), there's chance we can merge
> some or all hugepd formats with cont_pte in the future.  That question is
> yet unsettled from Power side to have an acknowledgement.  As of now for
> this series, I kept the hugepd handling because we may still need to do so
> before getting a clearer picture of the future of hugepd.  The other reason
> is simply that we did it already for fast-gup and most codes are still
> around to be reused.  It'll make more sense to keep slow/fast gup behave
> the same before a decision is made to remove hugepd.
> 

It is not true that hugepd is a software-only solution. Powerpc 8xx HW 
matches the hugepd topology for 8M pages.

Christophe