Well this is double crap. First of all SLUB does not do memclear twice.
There is no reason to assume that SLUB has the problem just because SLOB
hat that. A "fix" for that nonexistent problem went into Linus tree. WTH
is going on?
SLUB was done because of a series of problem with the basic concepts of
SLAB that treaten it usability in the future.
I agree, SLABs architecture is pretty tight and I was one of those who
helped it along to be that way.
However, SLAB is just fundamentally wrong for todays machine. The key
problem today is cacheline fetch latency and that problem will increase
significantly in the future. Sure under some circumstances that exploit
the fact that SLAB sometimes gets its guesses on the cpu cache right SLAB
can still win but the more processors and nodes we get the more it will
become difficult to keep SLAB around and the more it will become
difficult to establish what cachelines are in the cpu cache.
If you guarantee that all the regression of SLAB vs. SLUB are addressed
then thats fine but AFAICT that is not possible.
Here is a list of some of the benefits of SLUB just in case we forgot:
- SLUB is performance wise much faster than SLAB. This can be more than a
factor of 10 (case of concurrent allocations / frees on multiple
processors). See http://lkml.org/lkml/2007/10/27/245
- Single threaded allocation speed is up to double that of SLAB
- Remote freeing of objectcs in a NUMA systems is typically 30% faster.
- Debugging on SLAB is difficult. Requires recompile of the kernel
and the resulting output is difficult to interpret. SLUB can apply
debugging options to a subset of the slabcaches in order to allow
the system to work with maximum speed. This is necessary to detect
difficult to reproduce race conditions.
- SLAB can capture huge amounts of memory in its queues. The problem
gets worse the more processors and NUMA nodes are in the system. The
amount of memory limits the number of per cpu objects one can configure.
- SLAB requires a pass through all slab caches every 2 seconds to
expire objects. This is a problem both for realtime and MPI jobs
that cannot take such a processor outage.
- SLAB does not have a sophisticated slabinfo tool to report the
state of slab objects on the system. Can provide details of
object use.
- SLAB requires the update of two words for freeing
and allocation. SLUB can do that by updating a single
word which allows to avoid enabling and disabling interrupts if
the processor supports an atomic instruction for that purpose.
This is important for realtime kernels where special measures
may have to be implemented if one wants to disable interrupts.
- SLAB requires memory to be set aside for queues (processors
times number of slabs times queue size). SLUB requires none of that.
- SLUB merges slab caches with similar characteristics to
reduce the memory footprint even further.
- SLAB performs object level NUMA management which creates
a complex allocator complexity. SLUB manages NUMA on the level of
slab pages reducing object management overhead.
- SLUB allows remote node defragmentation to avoid the buildup
of large partial lists on a single node.
- SLUB can actively reduce the fragmentation of slabs through
slab cache specific callbacks (not merged yet)
- SLUB has resiliency features that allow it to isolate a problem
object and continue after diagnostics have been performed.
- SLUB creates rarely used DMA caches on demand instead of creating
them all on bootup (SLAB).
--
