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 SLAB. It's possible that there could be some benefit from using SLUB for the uniprocessor configurations. Ben. -- Ben Hutchings Horngren's Observation: Among economists, the real world is often a special case.
Description: This is a digitally signed message part