A pair of memory-allocation improvements in Linux 5.13

Re:A pair of memory-allocation improvements in Linux 5.13 by WalterGR on Thursday May 13, 2021 @02:07AM (#27138959)

Writing or using an existing custom allocator is common enough. Networking developer Jesper Dangaard Brouer must have looked into that approach and found it wanting for what the article describes as “The networking code could then grab a pile of memory, and quickly hand out pages as needed.”

What does the improvement described in the “Batch page allocation” section add that a custom allocator would be unable to? Or is it a widely-used pattern that many custom allocators can take advantage of? In that case, why put it in the kernel?

Etc.

[ Parent | on HN ]

Re:A pair of memory-allocation improvements in Linux 5.13 by teloli on Thursday May 13, 2021 @02:24AM (#27139041)

The kernel allocates memory too, hence an improvement at that level benefits allocations across the board.

[ Parent | on HN ]

Re:A pair of memory-allocation improvements in Linux 5.13 by WalterGR on Thursday May 13, 2021 @02:29AM (#27139078)

So the use case described by Brouer was for networking code in the kernel? The article explicitly mentions his use case as the ‘original’ motivation, regardless of whether that’s the primary use case.

Is the kernel then the primary place this is used now? Which places in the kernel need and take advantage of it?

[ Parent | on HN ]

Re:A pair of memory-allocation improvements in Linux 5.13 by DoomHotel on Thursday May 13, 2021 @03:14AM (#27139289)

The Sun RPC code had a loop where it allocated one page at a time and filled an array with the returned pointers. The article says there was a 500% performance improvement after replacing the loop with a single call to the batch allocator. (While RPC can be thought of as networking code, it is more than just network packet flow.)

There are probably other places where this will help. Now that the interface is available, developers can start trying it.

[ Parent | on HN ]