Re: what is the purpose of SLAB and SLUB

[Christoph Lameter <cl@linux.com>]

On Thu, 25 Aug 2016, Michal Hocko wrote:
> I can completely see how having multiple allocators (schedulers etc...)
> Because as of now, most users are using whatever is the default (SLUB
> for some and never documented reason) or what their distributions come
> up with. This means that we have quite a lot of code which only few
> people understand deeply. Some features which are added on top need much
> more testing to cover both allocators or we are risking subtle
> regressions.

I think the default is clear and advisable to use. The debugging features
in SLAB f.e. are problematic and I have had to ask at times to retry with
SLUB in order to find a subtle issue.

I think the main activity nowadays is to make SLAB competitive by adopting
methods from SLUB. Maybe that will work. But then concepts from SLAB can
also be used in SLUB and enhance speed there.

> Flexibility is always good but there comes a maintenance burden. Both
> should be weighed properly.

Well I thought we had that under control. SLAB is a legacy issue in many
ways and people are used to the problems with debuggability if they still
use that. There is always the simple way to just switch to SLUB
temporarily in order to find issues.


> Sure, but even after attempts to make some code common we are still at
> $ wc -l mm/slab.c mm/slub.c
> 	4479 mm/slab.c
> 	5727 mm/slub.c
> 	10206 total
>
> quite a lot, don't you think?

Well the code is always growing since features are being added like
cgroups support and the batch allocation/freeing that is used to improve
the network performance. I think this is actually quite reasonable
compared with other parts of our kernel.