From: David Hildenbrand <david@redhat.com>
To: Jiri Slaby <jirislaby@kernel.org>,
Matthew Wilcox <willy@infradead.org>,
Mike Rapoport <rppt@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Brendan Jackman <jackmanb@google.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Johannes Weiner <hannes@cmpxchg.org>,
Julia Lawall <Julia.Lawall@inria.fr>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
Michal Hocko <mhocko@suse.com>,
Suren Baghdasaryan <surenb@google.com>,
Vlastimil Babka <vbabka@suse.cz>, Zi Yan <ziy@nvidia.com>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [PATCH 0/3] mm: treewide: make get_free_pages() and return void *
Date: Mon, 20 Oct 2025 11:02:11 +0200 [thread overview]
Message-ID: <635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com> (raw)
In-Reply-To: <85707316-3f2b-4e29-b821-a32f9097244e@kernel.org>
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
next prev parent reply other threads:[~2025-10-20 9:02 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-10-18 9:29 Mike Rapoport
2025-10-18 9:30 ` [PATCH 1/3] mm, vc_screen: move __free() handler that frees a page to a common header Mike Rapoport
2025-10-18 17:59 ` Jiri Slaby
2025-10-18 9:30 ` [PATCH 2/3] mm, treewide: make get_free_pages() and friends return void * Mike Rapoport
2025-10-18 9:30 ` [PATCH 3/3] mm, treewide: make addr parameter of free_pages() " Mike Rapoport
2025-10-19 0:30 ` [PATCH 0/3] mm: treewide: make get_free_pages() and return " Matthew Wilcox
2025-10-19 14:25 ` Mike Rapoport
2025-10-20 8:54 ` Vlastimil Babka
2025-10-20 9:04 ` Jiri Slaby
2025-10-20 14:22 ` Mike Rapoport
2025-10-20 9:06 ` David Hildenbrand
2025-10-20 14:20 ` Mike Rapoport
2025-10-20 6:58 ` Jiri Slaby
2025-10-20 7:06 ` Jiri Slaby
2025-10-20 9:02 ` David Hildenbrand [this message]
2025-10-20 9:08 ` Jiri Slaby
2025-10-20 9:13 ` David Hildenbrand
2025-10-20 10:31 ` Vlastimil Babka
2025-10-20 11:21 ` David Hildenbrand
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=635405e4-9423-4a25-a6e7-e03c8ea0bcbe@redhat.com \
--to=david@redhat.com \
--cc=Julia.Lawall@inria.fr \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=jackmanb@google.com \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=mhocko@suse.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox