Re: [PATCH 0/3] mm: treewide: make get_free_pages() and return void *

[David Hildenbrand <david@redhat.com>]

On 20.10.25 12:31, Vlastimil Babka wrote:
> On 10/20/25 11:13, David Hildenbrand wrote:
>> On 20.10.25 11:08, Jiri Slaby wrote:
>>> On 20. 10. 25, 11:02, David Hildenbrand wrote:
>>>> Regarding the metadata overhead, in 2015 Linus wrote in that thread:
>>>>
>>>> "Long ago, allocating a page using kmalloc() was a bad idea, because
>>>> there was overhead for it in the allocation and the code.
>>>>
>>>> These days, kmalloc() not only doesn't have the allocation overhead,
>>>> but may actually scale better too, thanks to percpu caches etc."
>>>>
>>>> What's that status of that 10 years later?
>>>
>>> AFAI skimmed through the code, for allocations > 2 pages
>>> (KMALLOC_MAX_CACHE_SIZE) -- if size is a constant -- slub resorts to
>>> alloc_pages().
>>>
>>> For smaller ones (1 and 2 pages), there is a very little overhead in
>>> struct slab -- mm people, please correct me if I am wrong.
>>
>> If it's really only "struct slab", then there is currently no overhead.
>> Once it is decoupled from "struct page", there would be some.
> 
> Yes, but there's potentially better scalability and more debugging
> possibilities as benefits.

Agreed.

> 
>> IIUC, I'm surprised that larger allocations wouldn't currently end up in
>> PageSlab() pages.
> Can you elaborate why surprised?

Primarily because I think it's a bit inconsistent. I would have assumed 
that whatever came out of kmalloc() could be identified as such.

One of the benefits of PageSlab() is that we can better sanity check 
that these pages will not get mapped into user space by accident: see 
page_has_type() check in validate_page_before_insert().

But given that ___kmalloc_large_node() today also allocates frozen 
pages, validate_page_before_insert() would similarly bail out if it 
stumbles over the !folio_ref_count(folio).

-- 
Cheers

David / dhildenb