linux-kernel - Re: what is the purpose of SLAB and SLUB

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 25 Aug 2016 14:49:53 -0500 (CDT)
From:   Christoph Lameter <cl@...ux.com>
To:     Michal Hocko <mhocko@...nel.org>
cc:     Andi Kleen <andi@...stfloor.org>,
        Joonsoo Kim <iamjoonsoo.kim@....com>,
        Aruna Ramakrishna <aruna.ramakrishna@...cle.com>,
        linux-mm@...ck.org, linux-kernel@...r.kernel.org,
        Mike Kravetz <mike.kravetz@...cle.com>,
        Pekka Enberg <penberg@...nel.org>,
        David Rientjes <rientjes@...gle.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Mel Gorman <mgorman@...e.de>, Jiri Slaby <jslaby@...e.cz>
Subject: Re: what is the purpose of SLAB and SLUB

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.