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?