Choose SLAB allocator (SLUB (Unqueued Allocator)) --->

This is a configuration option in the Linux kernel that allows the user to choose between two different memory allocators: SLAB and SLUB. SLUB is the default allocator in newer versions of the kernel and is considered to be an improved version of SLAB.

SLUB is an unqueued memory allocator that provides better performance and scalability compared to SLAB. It reduces lock contention by using per-CPU caches and avoids unnecessary memory fragmentation.

To choose SLUB as the memory allocator in the Linux kernel, you can select the " SLUB(Unqueued Allocator)" option in the kernel configuration menu.

相关问题

Choose SLAB allocator (SLUB (Unqueued Allocator)) ---> 内核配置项介绍

SLUB (Unqueued Allocator) 是 Linux 内核中的一种内存分配器，它用于动态地分配内核对象，比如进程控制块、文件描述符等。相比于传统的 SLAB 分配器，SLUB 更加简单、高效，且在高并发场景下表现更好。

在内核编译时，可以通过配置选项选择是否启用 SLUB 分配器。具体的配置选项为：

CONFIG_SLUB：该选项用于启用或禁用 SLUB 分配器。如果选择了该选项，则表示启用 SLUB 分配器。

如果不启用该选项，则表示使用传统的 SLAB 分配器。

需要注意的是，在使用 SLUB 分配器时，可能会因为一些特定的硬件或内核配置导致系统不稳定，因此在使用 SLUB 分配器时需要谨慎。

linux slub

### Linux Kernel SLUB Memory Allocator Overview

The SLUB (Simple Low-overhead Unbounded) allocator is a successor to the earlier SLAB allocator found in older versions of the Linux kernel. This allocator aims at providing efficient management of small objects while reducing fragmentation and overheads associated with managing these allocations.

#### Key Features

One significant advantage lies within its design simplicity compared to predecessors like SLAB or SLOB, making it easier for developers to understand how memory allocation works internally without sacrificing performance efficiency[^2].

In addition, unlike previous allocators that required maintaining complex data structures such as queues holding partially allocated slabs, SLUB uses only one queue per cache named `partial`. It keeps track of all partially filled pages ready for reuse when new requests come in. Such an approach minimizes contention between threads trying simultaneously access shared resources during high-concurrency scenarios.

Another notable feature introduced by SLUB includes support for hardware-based red zoning which helps detect buffer overflows more effectively than software methods alone could achieve. By placing guard zones around each object stored inside a slab page, any overflow attempting to corrupt adjacent areas will trigger immediate detection mechanisms provided either through CPU-specific instructions or external tools monitoring system behavior.

#### Usage Example

Below demonstrates basic usage patterns involving dynamic creation/destruction operations on custom-defined types using kmalloc() & kfree():

#include <linux/slab.h>

// Define structure type.
struct my_data {
    int value;
};

void example_function(void){
    struct my_data *ptr;

    // Allocate space from SLUB managed pool.
    ptr = kmalloc(sizeof(struct my_data), GFP_KERNEL);
    
    if (!ptr)
        return; /* Handle error */

    // Initialize your variable here...
    ptr->value = 42;

    // Free previously reserved area back into free list once done.
    kfree(ptr); 
}

This code snippet shows allocating a single instance of `my_data` via `kmalloc()` followed later by freeing this same block after use has concluded utilizing `kfree()`. Both functions operate under control exerted indirectly upon them thanks largely due implementation details embedded deep within SLUB's core logic layers.

--related questions--

1. How does SLUB handle concurrent accesses better than other allocators?
2. What are some common debugging techniques used specifically for diagnosing issues related to SLUB?
3. Can you explain what happens behind the scenes when calling kmalloc/kfree in terms of SLUB interactions?
4. Is there any way to tune parameters affecting SLUB’s operation directly? If so, where can they be configured?
5. In comparison with SLAB/SLOB, why was SLUB chosen as the default allocator starting certain kernel releases?