Re: [PATCH] block: partitions: replace __get_free_page() with kmalloc()
From: Hannes Reinecke
Date: Wed May 27 2026 - 06:05:09 EST
On 5/26/26 22:57, Vlastimil Babka wrote:
On 5/26/26 16:37, Matthew Wilcox wrote:Precisely my reasoning. In most cases, __get_free_page() is just a
On Tue, May 26, 2026 at 02:07:36PM +0200, Vlastimil Babka wrote:
The main reasons for switching AFAIU would be related with the
folio/memdesc conversions? If one needs just a kernel memory buffer,
kmalloc() it is, even if it happens to be page size. Page allocator
should be only used if you need e.g. the refcounting or anything else
that struct page provides. But then in some cases the memdesc conversion
would need adjustments at some point. With kmalloc() we can forget about
this user.
No, I think this is unrelated to memdescs.
I've seen a few people say slightly wrong things about
folios/pages/memdescs recently, so let me try to clarify the end state.
I do not intend to get rid of the ability to allocate a bare page of
memory with something like alloc_pages() or get_free_page(). It's
just that the struct page associated with it will contain far less
information (because it's smaller).
Alright, but isn't it still the case that if you don't need any of what
struct page provides today or will do in the future, it's better if you just
use kmalloc()? I thought you said so yourself?
https://lore.kernel.org/all/aPQxN7-FeFB6vTuv@xxxxxxxxxxxxxxxxxxxx/
lazy way of saying "I need some memory and the allocation should not fail". And typically these callers don't really care about the page
mapping, too.
Additionally, these applications get in the way when using large block
sizes on the system, as they needlessly increase the pressure on
compaction.
So switching them over to kmalloc() is a good thing IMO.
If nothing else it allows us to differentiate which places _actually_
need struct page, and which callers just want to do a memory allocation.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich