linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Kiryl Shutsemau <kas@kernel.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	 Muchun Song <muchun.song@linux.dev>,
	Matthew Wilcox <willy@infradead.org>,
	 Usama Arif <usamaarif642@gmail.com>,
	Frank van der Linden <fvdl@google.com>,
	 Oscar Salvador <osalvador@suse.de>,
	Mike Rapoport <rppt@kernel.org>,
	 Vlastimil Babka <vbabka@suse.cz>,
	Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	 Zi Yan <ziy@nvidia.com>, Baoquan He <bhe@redhat.com>,
	Michal Hocko <mhocko@suse.com>,
	 Johannes Weiner <hannes@cmpxchg.org>,
	Jonathan Corbet <corbet@lwn.net>,
	 Huacai Chen <chenhuacai@kernel.org>,
	WANG Xuerui <kernel@xen0n.name>,
	 Palmer Dabbelt <palmer@dabbelt.com>,
	Paul Walmsley <paul.walmsley@sifive.com>,
	 Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	kernel-team@meta.com,  linux-mm@kvack.org,
	linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org,
	 loongarch@lists.linux.dev, linux-riscv@lists.infradead.org
Subject: Re: [PATCHv6 06/17] LoongArch/mm: Align vmemmap to maximal folio size
Date: Thu, 5 Feb 2026 13:43:58 +0000	[thread overview]
Message-ID: <aYSdW2YaJdpgXYos@thinkstation> (raw)
In-Reply-To: <062900fa-6419-4748-81d1-9128ce6c46d0@kernel.org>

On Thu, Feb 05, 2026 at 01:56:36PM +0100, David Hildenbrand (Arm) wrote:
> On 2/4/26 17:56, David Hildenbrand (arm) wrote:
> > On 2/2/26 16:56, Kiryl Shutsemau wrote:
> > > The upcoming change to the HugeTLB vmemmap optimization (HVO) requires
> > > struct pages of the head page to be naturally aligned with regard to the
> > > folio size.
> > > 
> > > Align vmemmap to MAX_FOLIO_NR_PAGES.
> > > 
> > > Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
> > > ---
> > >   arch/loongarch/include/asm/pgtable.h | 3 ++-
> > >   1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/arch/loongarch/include/asm/pgtable.h b/arch/loongarch/
> > > include/asm/pgtable.h
> > > index c33b3bcb733e..f9416acb9156 100644
> > > --- a/arch/loongarch/include/asm/pgtable.h
> > > +++ b/arch/loongarch/include/asm/pgtable.h
> > > @@ -113,7 +113,8 @@ extern unsigned long empty_zero_page[PAGE_SIZE /
> > > sizeof(unsigned long)];
> > >        min(PTRS_PER_PGD * PTRS_PER_PUD * PTRS_PER_PMD * PTRS_PER_PTE
> > > * PAGE_SIZE, (1UL << cpu_vabits) / 2) - PMD_SIZE - VMEMMAP_SIZE -
> > > KFENCE_AREA_SIZE)
> > >   #endif
> > > -#define vmemmap        ((struct page *)((VMALLOC_END + PMD_SIZE) &
> > > PMD_MASK))
> > > +#define VMEMMAP_ALIGN    max(PMD_SIZE, MAX_FOLIO_NR_PAGES *
> > > sizeof(struct page))
> > > +#define vmemmap        ((struct page *)(ALIGN(VMALLOC_END,
> > > VMEMMAP_ALIGN)))
> > 
> > 
> > Same comment, the "MAX_FOLIO_NR_PAGES * sizeof(struct page)" is just
> > black magic here
> > and the description of the situation is wrong.
> > 
> > Maybe you want to pull the magic "MAX_FOLIO_NR_PAGES * sizeof(struct
> > page)" into the core and call it
> > 
> > #define MAX_FOLIO_VMEMMAP_ALIGN    (MAX_FOLIO_NR_PAGES * sizeof(struct
> > page))
> > 
> > But then special case it base on (a) HVO being configured in an (b) HVO
> > being possible
> > 
> > #ifdef HUGETLB_PAGE_OPTIMIZE_VMEMMAP && is_power_of_2(sizeof(struct page)
> > /* A very helpful comment explaining the situation. */
> > #define MAX_FOLIO_VMEMMAP_ALIGN    (MAX_FOLIO_NR_PAGES * sizeof(struct
> > page))
> > #else
> > #define MAX_FOLIO_VMEMMAP_ALIGN    0
> > #endif
> > 
> > Something like that.
> > 
> 
> Thinking about this ...
> 
> the vmemmap start is always struct-page-aligned. Otherwise we'd be in
> trouble already.
> 
> Isn't it then sufficient to just align the start to MAX_FOLIO_NR_PAGES?
> 
> Let's assume sizeof(struct page) == 64 and MAX_FOLIO_NR_PAGES = 512 for
> simplicity.
> 
> vmemmap start would be multiples of 512 (0x0010000000).
> 
> 512, 1024, 1536, 2048 ...
> 
> Assume we have an 256-pages folio at 1536+256 = 0x111000000

s/0x/0b/, but okay.

> Assume we have the last page of that folio (0x011111111111), we would just
> get to the start of that folio by AND-ing with ~(256-1).
> 
> Which case am I ignoring?

IIUC, you are ignoring the actual size of struct page. It is not 1 byte :P

The last page of this 256-page folio is at 1536+256 + (64 * 255) which
is 0b100011011000000. There's no mask that you can AND that gets you to
0b11100000000.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov


  reply	other threads:[~2026-02-05 13:44 UTC|newest]

Thread overview: 67+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-02-02 15:56 [PATCHv6 00/17] mm: Eliminate fake head pages from vmemmap optimization Kiryl Shutsemau
2026-02-02 15:56 ` [PATCHv6 01/17] mm: Move MAX_FOLIO_ORDER definition to mmzone.h Kiryl Shutsemau
2026-02-07 20:20   ` Usama Arif
2026-02-10 15:01   ` Vlastimil Babka
2026-02-02 15:56 ` [PATCHv6 02/17] mm: Change the interface of prep_compound_tail() Kiryl Shutsemau
2026-02-04 16:14   ` David Hildenbrand (arm)
2026-02-05 11:35     ` Kiryl Shutsemau
2026-02-05 11:58       ` David Hildenbrand (arm)
2026-02-10 15:06   ` Vlastimil Babka
2026-02-02 15:56 ` [PATCHv6 03/17] mm: Rename the 'compound_head' field in the 'struct page' to 'compound_info' Kiryl Shutsemau
2026-02-04 16:14   ` David Hildenbrand (arm)
2026-02-10 15:09   ` Vlastimil Babka
2026-02-02 15:56 ` [PATCHv6 04/17] mm: Move set/clear_compound_head() next to compound_head() Kiryl Shutsemau
2026-02-04 16:35   ` David Hildenbrand (arm)
2026-02-10 15:10   ` Vlastimil Babka
2026-02-02 15:56 ` [PATCHv6 05/17] riscv/mm: Align vmemmap to maximal folio size Kiryl Shutsemau
2026-02-04 16:50   ` David Hildenbrand (arm)
2026-02-05 13:50     ` Kiryl Shutsemau
2026-02-05 13:54       ` David Hildenbrand (Arm)
2026-02-02 15:56 ` [PATCHv6 06/17] LoongArch/mm: " Kiryl Shutsemau
2026-02-04 16:56   ` David Hildenbrand (arm)
2026-02-05 12:56     ` David Hildenbrand (Arm)
2026-02-05 13:43       ` Kiryl Shutsemau [this message]
2026-02-05 13:52         ` David Hildenbrand (Arm)
2026-02-05 13:52     ` Kiryl Shutsemau
2026-02-05 13:57       ` David Hildenbrand (Arm)
2026-02-02 15:56 ` [PATCHv6 07/17] mm: Rework compound_head() for power-of-2 sizeof(struct page) Kiryl Shutsemau
2026-02-05 14:09   ` David Hildenbrand (Arm)
2026-02-07 20:19   ` Usama Arif
2026-02-10 15:40   ` Vlastimil Babka
2026-02-02 15:56 ` [PATCHv6 08/17] mm: Make page_zonenum() use head page Kiryl Shutsemau
2026-02-04  3:40   ` Muchun Song
2026-02-05 13:10   ` David Hildenbrand (Arm)
2026-02-09 11:52     ` Kiryl Shutsemau
2026-02-10 15:57       ` Vlastimil Babka
2026-02-16 11:30         ` Kiryl Shutsemau
2026-02-15 23:13   ` Matthew Wilcox
2026-02-16  9:06     ` David Hildenbrand (Arm)
2026-02-16 11:20       ` Vlastimil Babka
2026-02-02 15:56 ` [PATCHv6 09/17] mm/sparse: Check memmap alignment for compound_info_has_mask() Kiryl Shutsemau
2026-02-03  3:35   ` Muchun Song
2026-02-05 13:31   ` David Hildenbrand (Arm)
2026-02-05 13:58     ` David Hildenbrand (Arm)
2026-02-02 15:56 ` [PATCHv6 10/17] mm/hugetlb: Refactor code around vmemmap_walk Kiryl Shutsemau
2026-02-02 15:56 ` [PATCHv6 11/17] mm/hugetlb: Remove fake head pages Kiryl Shutsemau
2026-02-03  9:50   ` Muchun Song
2026-02-06  9:14   ` David Hildenbrand (Arm)
2026-02-06  9:36   ` David Hildenbrand (Arm)
2026-02-07 20:16   ` Usama Arif
2026-02-07 21:25     ` David Hildenbrand (Arm)
2026-02-07 22:50       ` Usama Arif
2026-02-02 15:56 ` [PATCHv6 12/17] mm: Drop fake head checks Kiryl Shutsemau
2026-02-06  9:41   ` David Hildenbrand (Arm)
2026-02-10 16:18   ` Vlastimil Babka
2026-02-02 15:56 ` [PATCHv6 13/17] hugetlb: Remove VMEMMAP_SYNCHRONIZE_RCU Kiryl Shutsemau
2026-02-06  9:42   ` David Hildenbrand (Arm)
2026-02-02 15:56 ` [PATCHv6 14/17] mm/hugetlb: Remove hugetlb_optimize_vmemmap_key static key Kiryl Shutsemau
2026-02-06  9:42   ` David Hildenbrand (Arm)
2026-02-02 15:56 ` [PATCHv6 15/17] mm: Remove the branch from compound_head() Kiryl Shutsemau
2026-02-06 10:23   ` David Hildenbrand (Arm)
2026-02-10 16:42   ` Vlastimil Babka
2026-02-02 15:56 ` [PATCHv6 16/17] hugetlb: Update vmemmap_dedup.rst Kiryl Shutsemau
2026-02-06 10:35   ` David Hildenbrand (Arm)
2026-02-02 15:56 ` [PATCHv6 17/17] mm/slab: Use compound_head() in page_slab() Kiryl Shutsemau
2026-02-04  3:39   ` Muchun Song
2026-02-06 10:42   ` David Hildenbrand (Arm)
2026-02-10 16:45   ` Vlastimil Babka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aYSdW2YaJdpgXYos@thinkstation \
    --to=kas@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=bhe@redhat.com \
    --cc=chenhuacai@kernel.org \
    --cc=corbet@lwn.net \
    --cc=david@kernel.org \
    --cc=fvdl@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=kernel-team@meta.com \
    --cc=kernel@xen0n.name \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=loongarch@lists.linux.dev \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mhocko@suse.com \
    --cc=muchun.song@linux.dev \
    --cc=osalvador@suse.de \
    --cc=palmer@dabbelt.com \
    --cc=paul.walmsley@sifive.com \
    --cc=rppt@kernel.org \
    --cc=usamaarif642@gmail.com \
    --cc=vbabka@suse.cz \
    --cc=willy@infradead.org \
    --cc=ziy@nvidia.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox