[v5] mm: Eliminate fake head pages from vmemmap optimization

[PATCHv5 09/17] mm/sparse: Check memmap alignment for compound_info_has_mask()

Posted by Kiryl Shutsemau 1 week, 2 days ago

If page->compound_info encodes a mask, it is expected that vmemmap to be
naturally aligned to the maximum folio size.

Trigger a BUG() for CONFIG_DEBUG_VM=y or WARN() otherwise.

Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
Acked-by: Zi Yan <ziy@nvidia.com>
---
 mm/sparse.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/mm/sparse.c b/mm/sparse.c
index b5b2b6f7041b..9c0f4015778c 100644
--- a/mm/sparse.c
+++ b/mm/sparse.c
@@ -600,6 +600,19 @@ void __init sparse_init(void)
 	BUILD_BUG_ON(!is_power_of_2(sizeof(struct mem_section)));
 	memblocks_present();
 
+	if (compound_info_has_mask()) {
+		unsigned long alignment;
+		bool aligned;
+
+		alignment = MAX_FOLIO_NR_PAGES * sizeof(struct page);
+		aligned = IS_ALIGNED((unsigned long) pfn_to_page(0), alignment);
+
+		if (IS_ENABLED(CONFIG_DEBUG_VM))
+			BUG_ON(!aligned);
+		else
+			WARN_ON(!aligned);
+	}
+
 	pnum_begin = first_present_section_nr();
 	nid_begin = sparse_early_nid(__nr_to_section(pnum_begin));
 
-- 
2.51.2

Re: [PATCHv5 09/17] mm/sparse: Check memmap alignment for compound_info_has_mask()

Posted by Muchun Song 1 week, 2 days ago


> On Jan 28, 2026, at 21:54, Kiryl Shutsemau <kas@kernel.org> wrote:
> 
> If page->compound_info encodes a mask, it is expected that vmemmap to be
> naturally aligned to the maximum folio size.
> 
> Trigger a BUG() for CONFIG_DEBUG_VM=y or WARN() otherwise.
> 
> Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
> Acked-by: Zi Yan <ziy@nvidia.com>
> ---
> mm/sparse.c | 13 +++++++++++++
> 1 file changed, 13 insertions(+)
> 
> diff --git a/mm/sparse.c b/mm/sparse.c
> index b5b2b6f7041b..9c0f4015778c 100644
> --- a/mm/sparse.c
> +++ b/mm/sparse.c
> @@ -600,6 +600,19 @@ void __init sparse_init(void)
> BUILD_BUG_ON(!is_power_of_2(sizeof(struct mem_section)));
> 	memblocks_present();
> 
> + 	if (compound_info_has_mask()) {
> + 		unsigned long alignment;
> + 		bool aligned;
> +
> + 		alignment = MAX_FOLIO_NR_PAGES * sizeof(struct page);
> + 		aligned = IS_ALIGNED((unsigned long) pfn_to_page(0), alignment);
> +
> + 		if (IS_ENABLED(CONFIG_DEBUG_VM))
> + 			BUG_ON(!aligned);
> + 		else
> + 			WARN_ON(!aligned);

Since you’ve fixed all the problematic architectures, I don’t believe
we’ll ever hit the WARN or BUG here anymore.

I think we can now simplify the code further and just use VM_BUG_ON:
if any architecture changes in the future, the misalignment will be
caught during testing, so we won’t need to worry about it at run-time.

> + 	}
> +
> 	pnum_begin = first_present_section_nr();
> 	nid_begin = sparse_early_nid(__nr_to_section(pnum_begin));
> 
> -- 
> 2.51.2
>

Re: [PATCHv5 09/17] mm/sparse: Check memmap alignment for compound_info_has_mask()

Posted by Zi Yan 1 week, 2 days ago

On 28 Jan 2026, at 22:00, Muchun Song wrote:

>> On Jan 28, 2026, at 21:54, Kiryl Shutsemau <kas@kernel.org> wrote:
>>
>> If page->compound_info encodes a mask, it is expected that vmemmap to be
>> naturally aligned to the maximum folio size.
>>
>> Trigger a BUG() for CONFIG_DEBUG_VM=y or WARN() otherwise.
>>
>> Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
>> Acked-by: Zi Yan <ziy@nvidia.com>
>> ---
>> mm/sparse.c | 13 +++++++++++++
>> 1 file changed, 13 insertions(+)
>>
>> diff --git a/mm/sparse.c b/mm/sparse.c
>> index b5b2b6f7041b..9c0f4015778c 100644
>> --- a/mm/sparse.c
>> +++ b/mm/sparse.c
>> @@ -600,6 +600,19 @@ void __init sparse_init(void)
>> BUILD_BUG_ON(!is_power_of_2(sizeof(struct mem_section)));
>> 	memblocks_present();
>>
>> + 	if (compound_info_has_mask()) {
>> + 		unsigned long alignment;
>> + 		bool aligned;
>> +
>> + 		alignment = MAX_FOLIO_NR_PAGES * sizeof(struct page);
>> + 		aligned = IS_ALIGNED((unsigned long) pfn_to_page(0), alignment);
>> +
>> + 		if (IS_ENABLED(CONFIG_DEBUG_VM))
>> + 			BUG_ON(!aligned);
>> + 		else
>> + 			WARN_ON(!aligned);
>
> Since you’ve fixed all the problematic architectures, I don’t believe
> we’ll ever hit the WARN or BUG here anymore.
>
> I think we can now simplify the code further and just use VM_BUG_ON:
> if any architecture changes in the future, the misalignment will be
> caught during testing, so we won’t need to worry about it at run-time.
>

VM_WARN_ON should be sufficient, since bots should report warnings
from any patch/change.

>> + 	}
>> +
>> 	pnum_begin = first_present_section_nr();
>> 	nid_begin = sparse_early_nid(__nr_to_section(pnum_begin));
>>
>> -- 
>> 2.51.2
>>


Best Regards,
Yan, Zi

Re: [PATCHv5 09/17] mm/sparse: Check memmap alignment for compound_info_has_mask()

Posted by Muchun Song 1 week, 2 days ago


> On Jan 29, 2026, at 11:10, Zi Yan <ziy@nvidia.com> wrote:
> 
> On 28 Jan 2026, at 22:00, Muchun Song wrote:
> 
>>> On Jan 28, 2026, at 21:54, Kiryl Shutsemau <kas@kernel.org> wrote:
>>> 
>>> If page->compound_info encodes a mask, it is expected that vmemmap to be
>>> naturally aligned to the maximum folio size.
>>> 
>>> Trigger a BUG() for CONFIG_DEBUG_VM=y or WARN() otherwise.
>>> 
>>> Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
>>> Acked-by: Zi Yan <ziy@nvidia.com>
>>> ---
>>> mm/sparse.c | 13 +++++++++++++
>>> 1 file changed, 13 insertions(+)
>>> 
>>> diff --git a/mm/sparse.c b/mm/sparse.c
>>> index b5b2b6f7041b..9c0f4015778c 100644
>>> --- a/mm/sparse.c
>>> +++ b/mm/sparse.c
>>> @@ -600,6 +600,19 @@ void __init sparse_init(void)
>>> BUILD_BUG_ON(!is_power_of_2(sizeof(struct mem_section)));
>>> memblocks_present();
>>> 
>>> +  if (compound_info_has_mask()) {
>>> +  	unsigned long alignment;
>>> +  	bool aligned;
>>> +
>>> +  	alignment = MAX_FOLIO_NR_PAGES * sizeof(struct page);
>>> +  	aligned = IS_ALIGNED((unsigned long) pfn_to_page(0), alignment);
>>> +
>>> +  	if (IS_ENABLED(CONFIG_DEBUG_VM))
>>> +  		BUG_ON(!aligned);
>>> +  	else
>>> +  		WARN_ON(!aligned);
>> 
>> Since you’ve fixed all the problematic architectures, I don’t believe
>> we’ll ever hit the WARN or BUG here anymore.
>> 
>> I think we can now simplify the code further and just use VM_BUG_ON:
>> if any architecture changes in the future, the misalignment will be
>> caught during testing, so we won’t need to worry about it at run-time.
>> 
> 
> VM_WARN_ON should be sufficient, since bots should report warnings
> from any patch/change.

I’m not sure a WARN will get developers’ attention, since the message
is unlikely to have any visible consequences and only fires on
allocations with a special order.

> 
>>> +  }
>>> +
>>> pnum_begin = first_present_section_nr();
>>> nid_begin = sparse_early_nid(__nr_to_section(pnum_begin));
>>> 
>>> -- 
>>> 2.51.2
>>> 
> 
> 
> Best Regards,
> Yan, Zi

Re: [PATCHv5 09/17] mm/sparse: Check memmap alignment for compound_info_has_mask()

Posted by Zi Yan 1 week, 2 days ago

On 28 Jan 2026, at 22:23, Muchun Song wrote:

>> On Jan 29, 2026, at 11:10, Zi Yan <ziy@nvidia.com> wrote:
>>
>> On 28 Jan 2026, at 22:00, Muchun Song wrote:
>>
>>>> On Jan 28, 2026, at 21:54, Kiryl Shutsemau <kas@kernel.org> wrote:
>>>>
>>>> If page->compound_info encodes a mask, it is expected that vmemmap to be
>>>> naturally aligned to the maximum folio size.
>>>>
>>>> Trigger a BUG() for CONFIG_DEBUG_VM=y or WARN() otherwise.
>>>>
>>>> Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
>>>> Acked-by: Zi Yan <ziy@nvidia.com>
>>>> ---
>>>> mm/sparse.c | 13 +++++++++++++
>>>> 1 file changed, 13 insertions(+)
>>>>
>>>> diff --git a/mm/sparse.c b/mm/sparse.c
>>>> index b5b2b6f7041b..9c0f4015778c 100644
>>>> --- a/mm/sparse.c
>>>> +++ b/mm/sparse.c
>>>> @@ -600,6 +600,19 @@ void __init sparse_init(void)
>>>> BUILD_BUG_ON(!is_power_of_2(sizeof(struct mem_section)));
>>>> memblocks_present();
>>>>
>>>> +  if (compound_info_has_mask()) {
>>>> +  	unsigned long alignment;
>>>> +  	bool aligned;
>>>> +
>>>> +  	alignment = MAX_FOLIO_NR_PAGES * sizeof(struct page);
>>>> +  	aligned = IS_ALIGNED((unsigned long) pfn_to_page(0), alignment);
>>>> +
>>>> +  	if (IS_ENABLED(CONFIG_DEBUG_VM))
>>>> +  		BUG_ON(!aligned);
>>>> +  	else
>>>> +  		WARN_ON(!aligned);
>>>
>>> Since you’ve fixed all the problematic architectures, I don’t believe
>>> we’ll ever hit the WARN or BUG here anymore.
>>>
>>> I think we can now simplify the code further and just use VM_BUG_ON:
>>> if any architecture changes in the future, the misalignment will be
>>> caught during testing, so we won’t need to worry about it at run-time.
>>>
>>
>> VM_WARN_ON should be sufficient, since bots should report warnings
>> from any patch/change.
>
> I’m not sure a WARN will get developers’ attention, since the message
> is unlikely to have any visible consequences and only fires on
> allocations with a special order.

If a developer misses the WARN and the patch gets into linux-mm or linux-next,
kernel test robot runs selftests on the kernel and reports any warnings
to the mailing list. Do we have any related test in selftests/mm? That should
help us catch anything if a developer does not catch it.

Best Regards,
Yan, Zi

Re: [PATCHv5 09/17] mm/sparse: Check memmap alignment for compound_info_has_mask()

Posted by Muchun Song 1 week, 2 days ago


> On Jan 29, 2026, at 11:29, Zi Yan <ziy@nvidia.com> wrote:
> 
> On 28 Jan 2026, at 22:23, Muchun Song wrote:
> 
>>> On Jan 29, 2026, at 11:10, Zi Yan <ziy@nvidia.com> wrote:
>>> 
>>> On 28 Jan 2026, at 22:00, Muchun Song wrote:
>>> 
>>>>> On Jan 28, 2026, at 21:54, Kiryl Shutsemau <kas@kernel.org> wrote:
>>>>> 
>>>>> If page->compound_info encodes a mask, it is expected that vmemmap to be
>>>>> naturally aligned to the maximum folio size.
>>>>> 
>>>>> Trigger a BUG() for CONFIG_DEBUG_VM=y or WARN() otherwise.
>>>>> 
>>>>> Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
>>>>> Acked-by: Zi Yan <ziy@nvidia.com>
>>>>> ---
>>>>> mm/sparse.c | 13 +++++++++++++
>>>>> 1 file changed, 13 insertions(+)
>>>>> 
>>>>> diff --git a/mm/sparse.c b/mm/sparse.c
>>>>> index b5b2b6f7041b..9c0f4015778c 100644
>>>>> --- a/mm/sparse.c
>>>>> +++ b/mm/sparse.c
>>>>> @@ -600,6 +600,19 @@ void __init sparse_init(void)
>>>>> BUILD_BUG_ON(!is_power_of_2(sizeof(struct mem_section)));
>>>>> memblocks_present();
>>>>> 
>>>>> +  if (compound_info_has_mask()) {
>>>>> +   unsigned long alignment;
>>>>> +   bool aligned;
>>>>> +
>>>>> +   alignment = MAX_FOLIO_NR_PAGES * sizeof(struct page);
>>>>> +   aligned = IS_ALIGNED((unsigned long) pfn_to_page(0), alignment);
>>>>> +
>>>>> +   if (IS_ENABLED(CONFIG_DEBUG_VM))
>>>>> +   BUG_ON(!aligned);
>>>>> +   else
>>>>> +   WARN_ON(!aligned);
>>>> 
>>>> Since you’ve fixed all the problematic architectures, I don’t believe
>>>> we’ll ever hit the WARN or BUG here anymore.
>>>> 
>>>> I think we can now simplify the code further and just use VM_BUG_ON:
>>>> if any architecture changes in the future, the misalignment will be
>>>> caught during testing, so we won’t need to worry about it at run-time.
>>>> 
>>> 
>>> VM_WARN_ON should be sufficient, since bots should report warnings
>>> from any patch/change.
>> 
>> I’m not sure a WARN will get developers’ attention, since the message
>> is unlikely to have any visible consequences and only fires on
>> allocations with a special order.
> 
> If a developer misses the WARN and the patch gets into linux-mm or linux-next,
> kernel test robot runs selftests on the kernel and reports any warnings
> to the mailing list. Do we have any related test in selftests/mm? That should
> help us catch anything if a developer does not catch it.

I looked at the selftest and it doesn’t seem to have a test that
allocates at MAX_FOLIO_ORDER and checks that it works correctly.

> 
> Best Regards,
> Yan, Zi

Re: [PATCHv5 09/17] mm/sparse: Check memmap alignment for compound_info_has_mask()

Posted by Zi Yan 1 week, 1 day ago

On 29 Jan 2026, at 2:03, Muchun Song wrote:

>> On Jan 29, 2026, at 11:29, Zi Yan <ziy@nvidia.com> wrote:
>>
>> On 28 Jan 2026, at 22:23, Muchun Song wrote:
>>
>>>> On Jan 29, 2026, at 11:10, Zi Yan <ziy@nvidia.com> wrote:
>>>>
>>>> On 28 Jan 2026, at 22:00, Muchun Song wrote:
>>>>
>>>>>> On Jan 28, 2026, at 21:54, Kiryl Shutsemau <kas@kernel.org> wrote:
>>>>>>
>>>>>> If page->compound_info encodes a mask, it is expected that vmemmap to be
>>>>>> naturally aligned to the maximum folio size.
>>>>>>
>>>>>> Trigger a BUG() for CONFIG_DEBUG_VM=y or WARN() otherwise.
>>>>>>
>>>>>> Signed-off-by: Kiryl Shutsemau <kas@kernel.org>
>>>>>> Acked-by: Zi Yan <ziy@nvidia.com>
>>>>>> ---
>>>>>> mm/sparse.c | 13 +++++++++++++
>>>>>> 1 file changed, 13 insertions(+)
>>>>>>
>>>>>> diff --git a/mm/sparse.c b/mm/sparse.c
>>>>>> index b5b2b6f7041b..9c0f4015778c 100644
>>>>>> --- a/mm/sparse.c
>>>>>> +++ b/mm/sparse.c
>>>>>> @@ -600,6 +600,19 @@ void __init sparse_init(void)
>>>>>> BUILD_BUG_ON(!is_power_of_2(sizeof(struct mem_section)));
>>>>>> memblocks_present();
>>>>>>
>>>>>> +  if (compound_info_has_mask()) {
>>>>>> +   unsigned long alignment;
>>>>>> +   bool aligned;
>>>>>> +
>>>>>> +   alignment = MAX_FOLIO_NR_PAGES * sizeof(struct page);
>>>>>> +   aligned = IS_ALIGNED((unsigned long) pfn_to_page(0), alignment);
>>>>>> +
>>>>>> +   if (IS_ENABLED(CONFIG_DEBUG_VM))
>>>>>> +   BUG_ON(!aligned);
>>>>>> +   else
>>>>>> +   WARN_ON(!aligned);
>>>>>
>>>>> Since you’ve fixed all the problematic architectures, I don’t believe
>>>>> we’ll ever hit the WARN or BUG here anymore.
>>>>>
>>>>> I think we can now simplify the code further and just use VM_BUG_ON:
>>>>> if any architecture changes in the future, the misalignment will be
>>>>> caught during testing, so we won’t need to worry about it at run-time.
>>>>>
>>>>
>>>> VM_WARN_ON should be sufficient, since bots should report warnings
>>>> from any patch/change.
>>>
>>> I’m not sure a WARN will get developers’ attention, since the message
>>> is unlikely to have any visible consequences and only fires on
>>> allocations with a special order.
>>
>> If a developer misses the WARN and the patch gets into linux-mm or linux-next,
>> kernel test robot runs selftests on the kernel and reports any warnings
>> to the mailing list. Do we have any related test in selftests/mm? That should
>> help us catch anything if a developer does not catch it.
>
> I looked at the selftest and it doesn’t seem to have a test that
> allocates at MAX_FOLIO_ORDER and checks that it works correctly.

OK, we probably need a selftest for it. In terms of using VM_BUG_ON or
VM_WARN_ON, I leave that decision to you and Kiryl.

Thank you for the clarification.

Best Regards,
Yan, Zi