On 11/11/22 18:24, Josh Triplett wrote: > On Fri, Nov 11, 2022 at 08:49:57PM +0800, kernel test robot wrote: >> FYI, we noticed a +5395 bytes kernel size regression due to commit: >> >> commit: b7c873108294f0fd19c7e4d6b038a05375b3cd33 (Deprecating and removing SLOB) >> url: https://github.com/intel-lab-lkp/linux/commits/Vlastimil-Babka/mm-slob-rename-CONFIG_SLOB-to-CONFIG_SLOB_DEPRECATED/20221111-183529 >> base: https://git.kernel.org/cgit/linux/kernel/git/akpm/mm.git mm-everything >> patch subject: [PATCH] mm, slob: rename CONFIG_SLOB to CONFIG_SLOB_DEPRECATED >> >> >> Details as below (size data is obtained by `nm --size-sort vmlinux`): >> >> e1e3de44: Merge branch 'mm-nonmm-unstable' into mm-everything >> b7c87310: Deprecating and removing SLOB > > This patch has the net effect of switching tiny over from SLOB to SLUB, > which causes a 5k+ size regression. > > I *absolutely* appreciate the value of removing this much code, and I'm > not going to propose keeping SLOB for the sole reason of being 5k > smaller; it's not worth keeping a whole allocator for that. I also > wouldn't be surprised if we get *some* of that back by simplifications > this change enables in the rest of the kernel. +Cc more slab people and linux-mm, the lkp report is here: https://lore.kernel.org/all/Y25E9cJbhDAKi1vd@99bb1221be19/ Yeah, probably not immediately but if we succeed in removing SLAB as well, the mm/slab_common.c wrapper can go away which should reduce the code. > But I'm wondering if there might be any low-hanging fruit that could > slim down SLUB to the tune of 5k or so, that has been previously ignored > because SLOB served that use case? For instance, largely self-contained > bits of SLUB functionality that could be omitted on the tiniest of > systems? Maybe not the whole of 5k, but looking at the symbol sizes we could get something back with less aggressive inlining. Maybe add something like a SLUB_TINY config that sets the other configs correctly for minimal footprint and does tweaks like that to inlining or more code removal. Besides the code size, the less obvious but probably more important is how many slab pages it needs to allocate at runtime. E.g. for the configs, "make tinyconfig" seems to not set those like SLUB_DEBUG and SLUB_CPU_PARTIAL, which is good for making both code and page allocation smaller, but it also doesn't set SLAB_MERGE_DEFAULT which should result in fewer slab pages allocated if enabled. With SLUB_TINY we could also ditch completely percpu caches and associated code and just rely on the spin_lock protected partial list... > - Josh Triplett
