Facebook proposes a new slab memory management mechanism for the Linux kernel

Roman Gushchin (Roman Gushchin) from Facebook ΠΎΠΏΡƒΠ±Π»ΠΈΠΊΠΎΠ²Π°Π» in the mailing list of Linux kernel developers a set of patches with the implementation of a new memory allocation controller slab (slab memory controller). The new controller is notable for moving slab accounting from the memory page level to the kernel object level, which makes it possible to share slab pages across different cgroups, instead of having separate slab caches for each cgroup.

The proposed approach makes it possible to increase the efficiency of using slab, reduce the size of memory used for slab by 30-45%, and significantly reduce the overall memory consumption of the kernel. By reducing the number of non-relocatable slabs, there is also a positive effect in reducing memory fragmentation. The new memory controller significantly simplifies the code for slab accounting and does not require the use of complicated algorithms for dynamically creating and deleting slab caches for each cgroup. All cgroups for memory in the new implementation use a common set of slab caches, and the lifetime of slab caches is no longer tied to the lifetime of those set via cgroup restrictions on memory usage.

The more accurate resource accounting implemented in the new slab controller should theoretically load the CPU more, but in practice the differences turned out to be insignificant. In particular, the new slab controller has been in use on Facebook's production servers for several months now, handling various types of workload, and no noticeable regressions have yet been identified. At the same time, there is a significant reduction in memory consumption - on some hosts, we managed to save up to 1GB of memory, but this figure is highly dependent on the nature of the load, the total size of RAM, the number of CPUs, and the features of working with memory. Previously performed tests showed reduction in memory consumption by 650-700 MB (42% of slab memory) on the web frontend, 750-800 MB (35%) on the server with the DBMS cache and 700 MB (36%) on the DNS server.

Source: opennet.ru

Add a comment