[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: CONFIG_SLAB=y in 3.2 kernel

On Wed, 2012-03-28 at 14:38 -0400, Erik Lattimore wrote:
> Hi, I'm examining the 3.2 backported kernel for Squeeze and am
> wondering why the move away from CONFIG_SLUB (in 2.6.32) and
> CONFIG_SLUB_DEBUG to using CONFIG_SLAB in the 3.2 kernels. I thought
> the SLUB allocator was preferred with better debugging and supposed
> better performance. Is this no longer the case or was there another
> reason for the change?

The changelog is your friend:

  * mm: Select SLAB allocator again. Although SLUB is currently the
    upstream default, this was set as an experiment rather than a
    recommendation! SLUB generally has poorer performance than SLAB on
    larger systems.

SLUB is simpler than SLAB, but that simplicity hurts workloads that
involve allocating on one NUMA node and freeing on another - which is a
common behaviour when doing network or file I/O on a system with more
than one processor package.  Most distributions therefore still use

It's possible that there could be some benefit from using SLUB for the
uniprocessor configurations.


Ben Hutchings
Horngren's Observation:
                   Among economists, the real world is often a special case.

Attachment: signature.asc
Description: This is a digitally signed message part

Reply to: