Patches Posted For Removing The SLAB Allocator From The Linux Kernel
When the SLAB allocator was deprecated, Linux kernel developers wanted to hear from anyone where SLAB was necessary / SLUB wouldn't work... Well, several months later, apparently nothing substantive has come about and the upstream kernel maintainers are ready to send it off like Itanium (IA-64). Patches posted on Monday go ahead and would remove SLAB entirely from the kernel source tree.
Stripping out the SLAB allocator code from the Linux kernel frees up more than four thousand lines of code. The 4k line count isn't too significant considering the massive size of the kernel, but every little bit counts especially in freeing up technical debt and allowing kernel developers the ability to improve SLUB without worrying about legacy breakage concerns / maintaining that code.
Vlastimil Babka wrote in the patches dropping SLAB:
"The SLAB allocator has been deprecated since 6.5 and nobody has objected so far. As we agreed at LSF/MM, we should wait with the removal until the next LTS kernel is released. AFAIK that version hasn't been announced yet, but assuming it would be 6.7, we can aim for 6.8 and start exposing the removal to linux-next during the 6.7 cycle.
To keep the series reasonably sized and not pull in people from other subsystems than mm and closely related ones, I didn't attempt to remove every trace of unnecessary reference to dead config options in external areas, nor in the defconfigs. Such cleanups can be sent to and handled by respective maintainers after this is merged.
Instead I have added some patches aimed to reap some immediate benefits of the removal, mainly by not having to split some fastpath code between slab_common.c and slub.c anymore. But that is also not an exhaustive effort and I expect more cleanups and optimizations will follow later."
So if all goes well, Linux 6.8 could be the release that completely does away with SLAB. SLUB has been the default since the Linux 2.6.23 kernel.
2 Comments
