linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Kiryl Shutsemau <kas@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 14:52:27 +0100	[thread overview]
Message-ID: <460457b0-64c5-48a2-a5e4-d88ecc222884@kernel.org> (raw)
In-Reply-To: <aYSdW2YaJdpgXYos@thinkstation>

On 2/5/26 14:43, Kiryl Shutsemau wrote:
> On Thu, Feb 05, 2026 at 01:56:36PM +0100, David Hildenbrand (Arm) wrote:
>> On 2/4/26 17:56, David Hildenbrand (arm) wrote:
>>>
>>>
>>> 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

I thought it wouldn't matter but, yeah, that's it.

"Align the vmemmap to the maximum folio metadata size" it is.

Then you can explain the situation also alongside 
MAX_FOLIO_VMEMMAP_ALIGN, and that we expect this to be a power of 2.

-- 
Cheers,

David


  reply	other threads:[~2026-02-05 13:52 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
2026-02-05 13:52         ` David Hildenbrand (Arm) [this message]
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=460457b0-64c5-48a2-a5e4-d88ecc222884@kernel.org \
    --to=david@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=fvdl@google.com \
    --cc=hannes@cmpxchg.org \
    --cc=kas@kernel.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