[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com>
Date: Mon, 20 Oct 2025 11:02:11 +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 09:06, Jiri Slaby wrote:
> On 20. 10. 25, 8:58, Jiri Slaby wrote:
>> On 19. 10. 25, 2:30, Matthew Wilcox wrote:
>>> On Sat, Oct 18, 2025 at 12:29:59PM +0300, Mike Rapoport wrote:
>>>> Vast majority of allocations that use get_free_pages() and its
>>>> derivatives
>>>> cast the returned unsigned long to a pointer and then cast it back to
>>>> unsigned long when freeing the memory.
>>>>
>>>> These castings are useless and only obfuscate the code.
>>>>
>>>> Make get_free_pages() and friends return 'void *' and free_pages()
>>>> accept
>>>> 'void *' as its address parameter.
>>>
>>> No. Linus has rejected this change before. I can't find it now, it was
>>> a long time ago. Most of them shouldn't be using get_free_pages() at
>>> all, they should be using kmalloc().
>>
>> I'd be interested in the refusal thread (what was the rejection exactly
>> about). In a need of whole pages, why would I want to alloc more for
>> metadata (using k*alloc)? Or what am I missing?
>
> OK, AI yielded:
> https://lkml.iu.edu/1512.2/03853.html
> and an LWN summary:
> https://lwn.net/Articles/669015/
Right, the interesting stuff starts here I think:
https://lore.kernel.org/all/CA+55aFwp4iy4rtX2gE2WjBGFL=NxMVnoFeHqYa2j1dYOMMGqxg@mail.gmail.com/T/#u
Personally, I was always confused why we are even using "unsigned long"
in the first place.
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?
--
Cheers
David / dhildenb
Powered by blists - more mailing lists