接前一篇文章：Linux内核中内存管理相关配置项的详细解析3
二、SLAB allocator options
1. Choose SLAB allocator
此选项选择一个slab分配器。
此项展开后如下图所示：
- SLAB
对应配置变量为：CONFIG_SLAB。
内核源码详细解释为：
The regular slab allocator that is established and known to work
well in all environments. It organizes cache hot objects in
per cpu and per node queues.
已建立并已知在所有环境中都能很好地工作的常规slab分配器。它在每个cpu和每个节点队列中组织缓存热对象。
- SLUB (Unqueued Allocator)
对应配置变量为：CONFIG_SLUB。
此项为“Choose SLAB allocator”的默认选择。
内核源码详细解释为：
SLUB is a slab allocator that minimizes cache line usage
instead of managing queues of cached objects (SLAB approach).
Per cpu caching is realized using slabs of objects instead
of queues of objects. SLUB can use memory efficiently
and has enhanced diagnostics. SLUB is the default choice for
a slab allocator.
SLUB是一个slab分配器，它可以最大限度地减少缓存线的使用，而不是管理缓存对象的队列（slab方法）。每cpu缓存是使用slabs对象而不是对象队列来实现的。SLUB可以有效地使用内存，并具有增强的诊断功能。SLUB是slab分配器的默认选择。
- SLOB (Simple Allocator)
对应配置变量为：CONFIG_SLOB。
内核源码详细解释为：
SLOB replaces the stock allocator with a drastically simpler
allocator. SLOB is generally more space efficient but
does not perform as well on large systems.
SLOB用一个简单得多的分配器取代了stock allocator。SLOB通常更节省空间，但在大型系统上表现不佳。
2. Allow slab caches to be merged
对应配置变量为：CONFIG_SLAB_MERGE_DEFAULT。
此项只有选中和不选中两种状态，默认为选中。只有当上一项“Choose SLAB allocator”选择为“SLUB (Unqueued Allocator)”时，此项才会出现。
内核源码详细解释为：
For reduced kernel memory fragmentation, slab caches can be
merged when they share the same size and other characteristics.
This carries a risk of kernel heap overflows being able to
overwrite objects from merged caches (and more easily control
cache layout), which makes such heap attacks easier to exploit
by attackers. By keeping caches unmerged, these kinds of exploits
can usually only damage objects in the same cache. To disable
merging at runtime, "slab_nomerge" can be passed on the kernel
command line.
为了减少内核内存碎片，当slab缓存共享相同的大小和其他特性时，可以合并它们。这带来了内核堆溢出的风险——能够覆盖合并缓存中的对象（并且更容易控制缓存布局），这使得攻击者更容易利用此类堆攻击。通过保持缓存不合并，这类漏洞通常只能损坏同一缓存中的对象。要在运行时禁用合并，可以在内核命令行上传递“slab_nomerge”。
3. Randomize slab freelist
对应配置变量为：CONFIG_SLAB_FREELIST_RANDOM。
此项只有选中和不选中两种状态，默认为选中。只有当“Choose SLAB allocator”选择为“SLUB (Unqueued Allocator)”时，此项才会出现。
内核源码详细解释为：
Randomizes the freelist order used on creating new pages. This
security feature reduces the predictability of the kernel slab
allocator against heap overflows.
随机化创建新页面时使用的自由列表顺序。这个安全特性降低了内核slab分配器对堆溢出的可预测性。
4. Harden slab freelist metadata
对应配置变量为：CONFIG_SLAB_FREELIST_HARDENED。
此项只有选中和不选中两种状态，默认为选中。只有当“Choose SLAB allocator”选择为“SLUB (Unqueued Allocator)”时，此项才会出现。
内核源码详细解释为：
Many kernel heap attacks try to target slab cache metadata and
other infrastructure. This options makes minor performance
sacrifices to harden the kernel slab allocator against common
freelist exploit methods. Some slab implementations have more
sanity-checking than others. This option is most effective with
CONFIG_SLUB.
许多内核堆攻击试图以slab缓存元数据和其它基础设施为（攻击）目标。这些选项在针对常见的自由列表利用开发方法强化内核slab分配器方面做出了较小的性能牺牲。一些slab实现比其它实现具有更多的健全性检查。此选项对于CONFIG_SLUB中最为有效。
5. Enable SLUB performance statistics
对应配置变量为：CONFIG_SLUB_STATS。
此项只有选中和不选中两种状态，默认为不选中。只有当“Choose SLAB allocator”选择为“SLUB (Unqueued Allocator)”时，此项才会出现。
内核源码详细解释为：
SLUB statistics are useful to debug SLUBs allocation behavior in
order find ways to optimize the allocator. This should never be
enabled for production use since keeping statistics slows down
the allocator by a few percentage points. The slabinfo command
supports the determination of the most active slabs to figure
out which slabs are relevant to a particular load.
Try running: slabinfo -DA
SLUB统计信息有助于调试SLUB分配行为，以便找到优化分配器的方法。此项永远不应该为生产使用而启用（也就是说发布的产品中不应该启动此项），因为保持统计数据会使分配器慢几个百分点。slabinfo命令支持确定最活跃的slab，以确定哪些slab与特定荷载相关。
尝试运行：slabinfo-DA
6. SLUB per cpu partial cache
对应配置变量为：CONFIG_SLUB_CPU_PARTIAL。
此项只有选中和不选中两种状态，默认为选中。只有当“Choose SLAB allocator”选择为“SLUB (Unqueued Allocator)”时，此项才会出现。
内核源码详细解释为：
Per cpu partial caches accelerate objects allocation and freeing
that is local to a processor at the price of more indeterminism
in the latency of the free. On overflow these caches will be cleared
which requires the taking of locks that may cause latency spikes.
Typically one would choose no for a realtime system.
每cpu部分缓存加速了处理器本地的对象分配和释放，代价是释放的延迟更不确定。溢出时，这些缓存将被清除，这需要获取可能导致延迟峰值的锁。对于实时系统，通常会选择“否”。
