Re: [TECH TOPIC] Implementing malloc

"H. Peter Anvin" <[email protected]> Mon, 29 Jun 2026 11:22:12 -0700
Newsgroups dev.linux.lists.ksummit
Message-ID <[email protected]>
On June 29, 2026 11:19:20 AM PDT, Matthew Wilcox <[email protected]> wrote:
>On Mon, Jun 29, 2026 at 09:48:25AM -0700, H. Peter Anvin wrote:
>> On 2026-06-29 07:29, Matthew Wilcox wrote:
>> > malloc() is a standard part of the C library.  Yet we force new Linux
>> > programmers to learn the difference between vmalloc(), kmalloc() and
>> > kvmalloc().  They even have to acquire an understanding of the difference
>> > between GFP_KERNEL and GFP_ATOMIC.  If they are particularly unlucky,
>> > they may have to understand other combinations of GFP flags.
>> 
>> You *NEED* to understand that if you are going to program kernel code. There
>> probably isn't anything more important, *really*.
>
>There's a lot of kernel code where that's true.  malloc() is not The One
>True Interface to allocate memory, and at this point I'm not advocating
>for removing any of the existing ones.
>
>But we do have code which just needs to allocate "some memory", doesn't
>have any particularly weird restrictions, and where usability is more
>important than "pedal to the metal".  An example might be something
>like zlib.  It needs to allocate some temporary memory, and why have to
>
>#ifdef __KERNEL__
>#define malloc(x)	kvmalloc(x, GFP_KERNEL)
>#endif
>
>> The kernel is a memory manager first, a scheduler second, all else is commentary.
>
>Some filesystem people might have things to say about that.  But
>increasingly the kernel is just the runtime for eBPF programs ;-)
>

You *do* know that zlib gets passed an allocation function to it, and for good reason, right?