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

[Ankur Arora]

David Hildenbrand (Arm) <david@xxxxxxxxxx> 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?

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

--
ankur