linux-kernel - Re: [PATCH 0/3] mm: treewide: make get_free

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <a95df2f2-5ecc-4d28-9bcc-1f9b457b04a5@redhat.com>
Date: Mon, 20 Oct 2025 11:13:34 +0200
From: David Hildenbrand <david@...hat.com>
To: Jiri Slaby <jirislaby@...nel.org>, Matthew Wilcox <willy@...radead.org>,
 Mike Rapoport <rppt@...nel.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
 Brendan Jackman <jackmanb@...gle.com>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Johannes Weiner <hannes@...xchg.org>, Julia Lawall <Julia.Lawall@...ia.fr>,
 "Liam R. Howlett" <Liam.Howlett@...cle.com>,
 Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Michal Hocko
 <mhocko@...e.com>, Suren Baghdasaryan <surenb@...gle.com>,
 Vlastimil Babka <vbabka@...e.cz>, Zi Yan <ziy@...dia.com>,
 linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [PATCH 0/3] mm: treewide: make get_free_pages() and return void *

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.

IIUC, I'm surprised that larger allocations wouldn't currently end up in 
PageSlab() pages.

-- 
Cheers

David / dhildenb