Re: [PATCH 0/4] drivers/net: replace __get_free_pages() with kmalloc()
Paolo Abeni <[email protected]> Wed, 8 Jul 2026 10:55:51 +0200
| Newsgroups | org.infradead.lists.b43-dev,org.kernel.vger.linux-kernel,org.kernel.vger.linux-wireless,org.kernel.vger.netdev,org.kvack.linux-mm |
|---|---|
| Message-ID | <[email protected]> |
On 7/1/26 3:59 PM, Mike Rapoport (Microsoft) wrote: > This is a (small) part of larger work of replacing page allocator calls > with kmalloc. > > My initial intention a few month ago was to remove ugly casts [1], but then > willy pointed out that Linus objected to something like this [2] and it > looks like more than a decade old technical debt. > > Largely, anything that doesn't need struct page (or a memdesc in the > future) should just use kmalloc() or kvmalloc() to allocate memory. > kmalloc() guarantees alignment, physical contiguity and working > virt_to_phys() and beside nicer API that returns void * on alloc and > doesn't require to know the allocation size on free, kmalloc() provides > better debugging capabilities than page allocator. > > Another thing is that touching these allocation sites gives the reviewers > opportunity to see if a PAGE_SIZE buffer is actually needed or maybe > another size is appropriate. > > For larger allocations that don't need physically contiguous memory > kvmalloc() can be a better option that __get_free_pages() because under > memory pressure it's is easier to allocate several order-0 pages than a > physically contiguous chunk with the same number of pages. > > And last, but not least, removing needless calls to page allocator should > help with memdesc (aka project folio) conversion. There will be way less > places to audit to see if the user was actually using struct page. > > Also in git: > https://git.kernel.org/pub/scm/linux/kernel/git/rppt/linux.git gfp-to-kmalloc/drivers-net-wireless > > [1] https://lore.kernel.org/all/[email protected]/ > [2] https://lore.kernel.org/all/CA+55aFwp4iy4rtX2gE2WjBGFL=NxMVnoFeHqYa2j1dYOMMGqxg@mail.gmail.com/ > > --- @Johannes: just an head-up, I assume this series will go via your tree (despite the slightly misleading subj) /P _______________________________________________ b43-dev mailing list [email protected] http://lists.infradead.org/mailman/listinfo/b43-dev