The memory manager is a subset of the system operating It shares memory between the operating system and the various applications. The term memory refers mainly to main memory (RAM), but its management requires the contribution of auxiliary memory and cache memory.
The memory manager is especially responsible for efficiently allocating memory to processes, which implies that you must be able to enumerate the free locations of available memory, allocate the memory required for new processes, and reclaim memory from processes that terminate. The process dispatcher within the Linux kernel is the SLAB dispatcher.
SLAB relies on a block and cache system that optimizes memory requests. This type of memory management reduces fragmentation caused by allocation and relocation operations.
Block allocation involves implementing a cache for a certain object type / size that has several pre-allocated memory blocks cut into fixed-size pieces that are suitable for specific objects.
SLAB manages the pieces so that when the kernel is requested to allocate memory to an object, You can satisfy that request with a spare part from an existing block. SLAB retains the allocated memory for reuse, when subsequent allocations of similar objects, and thus reduces the overhead costs related to object initialization.
They intend to replace SLAB
Roman Gushchin, A member of the Linux kernel engineering team at Facebook, he discovered what he sees as a "serious flaw" in the current memory manager / controller. And rrecently proposed a new memory controller block which promises to dramatically improve memory utilization among multiple "cgroups" (or control groups) from memory.
Given this, it is important to note that cgroups refers to a feature of the Linux kernel that allows limiting, counting and isolating the use of a system's resources (processor, memory, disk usage, etc.) and the term "page of slab »could be assimilated to memory allocation process by SLAB.
According to Gushchin:
“The real reason the existing design leads to low SLAB usage is simple: slab pages are used exclusively by a single memory pool.
If there are only a few allocations of a certain size made by a cgroup or if there are some active objects left after the cgroup has been removed or if the cgroup contains a single threaded application that allocates virtually no kernels, but does so every time in a new CPU: In all these cases, the resulting SLAB usage is very low.
If kmem computation is disabled, the kernel can use free space on tile pages for other allocations «.
Gushchin argues that this was not a problem when the kmem driver was introduced as an optional feature that had to be enabled for each memory pool.
Now however, the kmem driver is enabled by default for cgroup v1 and v2. And since modern systems tend to create a large number of c groups, using SLAB is less effective.
According to him, by sharing the slab pages between various memory groups and by using a reworked system where accounting is done by object rather than by page, one would have in the linux kernel an optimized memory controller which offers a much more efficient level of use.
The patch proposed by Gushchin contains two semi-independent elements: a subpage load API that can be used in the future for accounting purposes and a mem_cgroup_ptr API.
Tests performed with the new controller memory of Gushchin have shown that it is possible to get between 35% and 42% more memory in Linux on the front-end web, the DNS server and database cache, and many other workloads.
Gushchin's proposal is currently under the banner of "request for comment." If accepted, it could be integrated into the 2020 Linux kernel release.
Source: https://lkml.org/