[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <3b97b754-890a-46c6-b892-a0324d529a3d@kernel.org>
Date: Mon, 20 Oct 2025 11:08:27 +0200
From: Jiri Slaby <jirislaby@...nel.org>
To: David Hildenbrand <david@...hat.com>, 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: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.
thanks,
--
js
suse labs
Powered by blists - more mailing lists