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

[David Hildenbrand (Arm)]

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.

Is the vmalloc address range guaranteed to be writable at that point?

-- 
Cheers,

David