This topic was published by DevynCJohnson and viewed 2450 times since "". The last page revision was "".
- Topics - 444
Linux has a few different methods of utilizing compressed memory pages and compressed memory cache. Compressed objects in memory reduces memory usage by data that may not be needed soon. This provides the system with more usable memory. When configuring the Linux kernel, it helps to understand the features and systems mentioned in this article. With a better understanding, a more efficient kernel can be made for the desired hardware.
Frontswap is used by the Linux kernel to manage swap devices whether they are on RAM or the hard-drive (like the Swap partition).
FUN FACT: Graphics cards with GDDR-SDRAM or DDR-SDRAM can be used as Swap by using the MTD kernel subsystem.
zbud is a memory allocator for compressed pages that can store two objects on a single page. However, zbud does not support highmem, unlike zsmalloc.
Like zRAM and zswap, zcache compresses memory pages on the RAM rather than storing them in Swap. This enhances system performance by reducing system I/O at the cost of additional CPU and memory usage. When accessing a zcache page, a whole page is accessed rather than a single byte at a time (like traditional memory storage). zcache can also compress pages stored in Swap.
zpool is a special memory pool allocator for compressed pages. Memory pools allow dynamic memory allocation using fixed-size blocks. With memory pools, software can allocate, access, and free blocks represented by handles at run time. "malloc" (the standard memory allocator) does not support compression or memory pools unlike zpool. Pools can be grouped in hierarchical tree structures which are beneficial for recursions and loops. Many page compression algorithms and features require zpool.
zRAM (formerly known as "compcache") provides a form of virtual memory compression that increases system performance. This performance boost is due to the kernel avoiding the need to place memory pages in the Swap-space, which is on the hard-drive. Compressing memory pages in memory (on RAM) instead of sending the pages to Swap avoids the additional latency associated hard-drives. Since RAM is much faster than the hard-drive, time can be saved by keeping the data in memory rather than sending it to the Swap. In fact, zRAM reserves a part of the RAM as a Swap partition in the form of a RAM block device.
If data is sent to a Swap partition, the data will be uncompressed before being written, thus harming system performance.
Using zRAM on systems that use a SSD (Solid-State Drive) storage device adds the additional benefit of reducing wear and tear on the SSD device. Android v4.4 (and later versions) use zRAM by default due to this advantage. If a system is using zRAM, a Swap partition/area is not required by the system. Obviously, zRAM is recommended for embedded systems and systems that use SSD devices.
On multi-core systems, it is strongly recommended that zRAM make a RAM block device for each core due to each zRAM device containing its own compression buffer, memory pools, and etc.
zRAM supports the LZO and LZ4 compression algorithms.
zsmalloc is a SLAB-based memory allocator for compressed pages that reduces memory fragmentation by using virtual memory mapping.
zswap provides support for compressed write-back cache for swapped pages. Like zRAM, usage of the Swap partition is avoided or reduced. Reducing the system's I/O usage benefits system performance at the cost of additional CPU usage. zswap utilizes and requires zbud.
If the memory gets too full, then zswap will allow some cached pages to be written to the Swap. Also, if the data cannot be compressed efficiently, then it will be written to the Swap partition. Systems that use zswap must have a Swap partition just in case the memory gets filled.
zswap supports the LZO, Deflate, and LZ4 compression algorithms. LZ4 is faster than LZO and Deflate, but it offers less compression.
- All About Swap - http://dcjtech.info/topic/all-about-swap/
- Linux Kernel Slab Allocators - http://dcjtech.info/topic/linux-kernel-slab-allocators/