Re: [PATCH v3] mm/page_alloc: replace kernel_init_pages() with batch page clearing

["Salunke, Hrushikesh" <hsalunke@amd.com>]

On 28-04-2026 14:01, Ankur Arora wrote:
> David Hildenbrand (Arm) <david@kernel.org> writes:
>
>> On 4/28/26 05:55, Salunke, Hrushikesh wrote:
>>> On 24-04-2026 14:22, David Hildenbrand (Arm) wrote:
>>>> Caution: This message originated from an External Source. Use proper caution when opening attachments, clicking links, or responding.
>>>>
>>>>
>>>> On 4/24/26 10:42, Salunke, Hrushikesh wrote:
>>>>> Hi Andrew,
>>>>>
>>>>> The idea was to keep it alongside clear_highpage_kasan_tagged() as its
>>>>> batch counterpart, but currently it is only used by page_alloc.c.
>>>> Right.
>>>>
>>>> Looking at init_vmalloc_pages(), I wonder if it could also benefit from batching
>>>> if we find that pages are actually contiguous.
>>>>
>>>> That would require looking up multiple pages at once. vmalloc_to_pages() or sth
>>>> like that. Surely, doing such an optimized page table walk could be beneficial
>>>> by itself.
>>> Interesting idea. For the general case where we only have struct page
>>> pointers, we'd need physical contiguity detection and a batched page
>>> table walk as you described. But looking at init_vmalloc_pages()
>>> specifically, it already has the vmalloc virtual address which is
>>> contiguous, so can we just do following and potentially skip the
>>> vmalloc_to_page() walk entirely:
>>>
>>> clear_pages(kasan_reset_tag((void *)start), size >> PAGE_SHIFT);
>>>
>>> What do you think? would this simpler approach work
>>> , or am I missing something?
>> Good question. :)
>>
>> That way you'd be operating on the vmalloc address range, not on the direct map.
> From my testing (including when using userspace VA) most of the speedup
> was from CPU prefetch. Which we should get when working with the
> vmalloc address range. Assuming it is writable and stable.
>
>> Is the vmalloc address range guaranteed to be writable at that point?

Hi David, Ankur

Yes. init_vmalloc_pages() is only reachable from
__kasan_unpoison_vmalloc() in hw_tags.c, and the only caller that
passes KASAN_VMALLOC_INIT is __vmalloc_node_range_noprof() in 
vmalloc.c. The pages are mapped by the time init_vmalloc_pages()
runs, so the vmalloc range is writable at that point.

> What happens if we get preempted and migrated while clearing? Seems like
> the vmalloc lazy syncing should be able to handle that?

Good point. I haven't looked into the vmalloc lazy syncing behavior
in this context yet. I'll need to look into that to make sure there are
no surprises with pre-emption and migration during clearing. Will
follow up on this.

Regards,
Hrushikesh.

>