On Wed 24-08-16 10:15:02, Joonsoo Kim wrote:

On Tue, Aug 23, 2016 at 05:38:08PM +0200, Michal Hocko wrote:

quoted

On Tue 23-08-16 11:13:03, Joonsoo Kim wrote:

quoted

On Thu, Aug 18, 2016 at 01:52:19PM +0200, Michal Hocko wrote:

[...]

quoted

quoted

I am not opposing the patch (to be honest it is quite neat) but this
is buggering me for quite some time. Sorry for hijacking this email
thread but I couldn't resist. Why are we trying to optimize SLAB and
slowly converge it to SLUB feature-wise. I always thought that SLAB
should remain stable and time challenged solution which works reasonably
well for many/most workloads, while SLUB is an optimized implementation
which experiment with slightly different concepts that might boost the
performance considerably but might also surprise from time to time. If
this is not the case then why do we have both of them in the kernel. It
is a lot of code and some features need tweaking both while only one
gets testing coverage. So this is mainly a question for maintainers. Why
do we maintain both and what is the purpose of them.

I don't know full history about it since I joined kernel communitiy
recently(?). Christoph would be a better candidate for this topic.
Anyway,

SLAB if SLUB beats SLAB completely. But, there are fundamental
differences in implementation detail so they cannot beat each other
for all the workloads. It is similar with filesystem case that various
filesystems exist for it's own workload.

Do we have any documentation/study about which particular workloads
benefit from which allocator? It seems that most users will use whatever
the default or what their distribution uses. E.g. SLES kernel use SLAB
because this is what we used to have for ages and there was no strong
reason to change that default. From such a perspective having a stable
allocator with minimum changes - just bug fixes - makes a lot of sense.

It doesn't make sense to me. Even if someone uses SLAB due to
conventional reason, they would want to use shiny new feature and get
performance improvement.

And, it is not only reason to use SLAB. There would be many different
reasons to use SLAB.

Could you be more specific please? Are there any inherent problems that
would make one allocator unsuitable for specific workloads?

quoted

I remember Mel doing some benchmarks when "why opensuse kernels do not
use the default SLUB allocator" came the last time and he didn't see any
large winner there
https://lists.opensuse.org/opensuse-kernel/2015-08/msg00098.html
This set of workloads is of course not comprehensive to rule one or
other but I am wondering whether there are still any pathological
workloads where we really want to keep SLAB or add new features to it.

AFAIK, some network benchmark still shows regression in SLUB.

http://lkml.kernel.org/r/20150907113026.5bb28ca3@redhat.com

That suggests that this is not an inherent problem of SLUB though.

-- 
Michal Hocko
SUSE Labs

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>