[LINUX] zswap

Originally, it is a part of the Linux Kernel source code, so it will be treated as GPLv2 (recognition that it should be).

https://www.kernel.org/doc/html/latest/index.html

Licensing documentation

The following describes the license of the Linux kernel source code (GPLv2), how to properly mark the license of individual files in the source tree, as well as links to the full license text.

https://www.kernel.org/doc/html/latest/process/license-rules.html#kernel-licensing

https://www.kernel.org/doc/html/latest/_sources/vm/zswap.rst.txt

zswap:

Overview

Zswap is a lightweight compressed cache for swap pages. It takes pages that are in the process of being swapped out and attempts to compress them into a dynamically allocated RAM-based memory pool. zswap basically trades CPU cycles for potentially reduced swap I/O. This trade-off can also result in a significant performance improvement if reads from the compressed cache are faster than reads from a swap device.

Zswap is a lightweight compressed cache for swap pages. It compresses and holds in a dynamically allocated RAM based memory pool when the process swapped out. zswap basically reduces swap I / O potentially and is a tread with CPU cycles. This trade-off can also result in significant performance gains if reads from the compressed cache are faster than reads from swap devices.

note::

Zswap is a new feature as of v3.11 and interacts heavily with memory reclaim. This interaction has not been fully explored on the large set of potential configurations and workloads that exist. For this reason, zswap is a work in progress and should be considered experimental.

Zswap is a new feature from v3.11 and interacts heavily with memory reuse. This interaction is not completely exposed to a large number of combinations of potential settings and the resulting loads. For this reason, zswap is still in the works and should be considered experimental.

Some potential benefits:

There are some potential benefits.

Desktop/laptop users with limited RAM capacities can mitigate the performance impact of swapping.

Overcommitted guests that share a common I/O resource can dramatically reduce their swap I/O pressure, avoiding heavy handed I/O throttling by the hypervisor. This allows more work to get done with less impact to the guest workload and guests sharing the I/O subsystem
Users with SSDs as swap devices can extend the life of the device by drastically reducing life-shortening writes.
Desktop / laptop users have limited RAM capacity, but can mitigate the performance impact of swapping.
Overcommit guests who share a common I / O resource can significantly reduce swap I / O pressure and eliminate the overload of I / O throttling by the hypervisor. This reduces the impact on guests who share the guest load and I / O subsytem, allowing more work to be done.
For users who use SSD as swap, it can significantly reduce the write that shortens the device life and extend the life of the device.

Zswap evicts pages from compressed cache on an LRU basis to the backing swap device when the compressed pool reaches its size limit. This requirement had been identified in prior community discussions.

Zswap evicts pages from the compressed cache to a backing swap device based on LRU. This requirement was previously found in community discussions.

Whether Zswap is enabled at the boot time depends on whether the CONFIG_ZSWAP_DEFAULT_ON Kconfig option is enabled or not.

Whether you enable Zswap at startup depends on whether the Kconfig option `` CONFIG_ZSWAP_DEFAULT_ON` is enabled or disabled.

This setting can then be overridden by providing the kernel command line zswap.enabled= option, for example zswap.enabled=0.

This setting can be overridden on the kernel command line by giving zswap.enabled = option. For example, zswap.enabled = 0.

Zswap can also be enabled and disabled at runtime using the sysfs interface.

Zswap can also be enabled / disabled during operation using the sysfs interface.

An example command to enable zswap at runtime, assuming sysfs is mounted at /sys, is::

The following is an example command to enable zswap in operation, assuming sysfs is mounted on / sys.

echo 1 > /sys/module/zswap/parameters/enabled

When zswap is disabled at runtime it will stop storing pages that are being swapped out. However, it will not immediately write out or fault back into memory all of the pages stored in the compressed pool. The pages stored in zswap will remain in the compressed pool until they are either invalidated or faulted back into memory. In order to force all pages out of the compressed pool, a swapoff on the swap device(s) will fault back into memory all swapped out pages, including those in the compressed pool.

If you stop Zswap while it's running, it will stop saving swapped pages. However, it does not immediately write out the pages in the compressed pool or fault back to memory. Pages listed in zswap are kept in the compressed pool until they are invalidated or faulted back in memory. To force all pages in the compressed pool to page out, you need to swap off the swap device and fauld back all swapped out pages that are also in the compressed pool to memory.

Design

Zswap receives pages for compression through the Frontswap API and is able to evict pages from its own compressed pool on an LRU basis and write them back to the backing swap device in the case that the compressed pool is full.

Zswap receives pages for compression through the frontswap API, expels pages from its compression pool based on LRU, and writes them to the backing swap device when the compression pool is full.

Zswap makes use of zpool for the managing the compressed memory pool. Each allocation in zpool is not directly accessible by address. Rather, a handle is returned by the allocation routine and that handle must be mapped before being accessed. The compressed memory pool grows on demand and shrinks as compressed pages are freed. The pool is not preallocated. By default, a zpool of type selected in CONFIG_ZSWAP_ZPOOL_DEFAULT Kconfig option is created, but it can be overridden at boot time by setting the zpool attribute,　e.g. zswap.zpool=zbud.

Zswap uses zpool to manage compressed memory pools. Each zpool allocation is not directly accessible by address. Rather, the handle is returned by the allocation routine and must be mapped before it can be accessed. The compressed memory pool expands on demand and shrinks when the compressed pool is freed. By default, it is created with the zpool type selected with the CONFIG_ZSWAP_ZPOOL_DEFAULT Kconfig option, but it can be overridden at startup by setting the zpool attribute. For example, zswap.zpool = zbud.

It can also be changed at runtime using the sysfs　zpool attribute, e.g.::

It can also be changed during operation using sysfs with the `zpool * attribute.

echo zbud > /sys/module/zswap/parameters/zpool

The zbud type zpool allocates exactly 1 page to store 2 compressed pages, which means the compression ratio will always be 2:1 or worse (because of half-full zbud pages). The zsmalloc type zpool has a more complex compressed page storage method, and it can achieve greater storage densities. However, zsmalloc does not implement compressed page eviction, so once zswap fills it cannot evict the oldest page, it can only reject new pages.

The zbud type zpool allocates exactly one page to two compressed pages, which means that the compression ratio is always 2: 1 or worse (because the zbud page is only half full). The zsmalloc type zpool is a more complex method of retaining compressed pages, which can increase storage density. However, zsmalloc does not implement compressed page exclusion, so when zswap is full, the oldest page cannot be eliminated and only new pages will be rejected.

When a swap page is passed from frontswap to zswap, zswap maintains a mapping of the swap entry, a combination of the swap type and swap offset, to the zpool handle that references that compressed swap page. This mapping is achieved with a red-black tree per swap type. The swap offset is the search key for the tree nodes.

When a swap page passes from frontswap to zswap, zswap keeps the swap entry mapping, the swap type and swap offset combination in the zpool handle that references the compressed swap page. This mapping is held by the red-black tree for swap type things. swap offset is the search key for the tree node.

During a page fault on a PTE that is a swap entry, frontswap calls the zswap load function to decompress the page into the page allocated by the page fault handler.

While a page fault is occurring on the swap entry PTE, frontswap calls the zswap load function to expand the page within the page allocated by the page fault handler.

Once there are no PTEs referencing a swap page stored in zswap (i.e. the count in the swap_map goes to 0) the swap code calls the zswap invalidate function, via frontswap, to free the compressed entry.

If the PTE that references the swap page held in zswap dies (that is, the swap_map counter reaches 0), the swap code will call the zswap invalidate function via ftontswap to release the compressed entry. I will.

Zswap seeks to be simple in its policies. Sysfs attributes allow for one user controlled policy:

zswap aims to keep the policy simple. The sysfs attribute implements one user control policy.

max_pool_percent - The maximum percentage of memory that the compressed pool can occupy.

max_pool_percent --Maximum percentage of memory that a compressed pool can occupy

The default compressor is selected in CONFIG_ZSWAP_COMPRESSOR_DEFAULT Kconfig option, but it can be overridden at boot time by setting the compressor attribute, e.g. zswap.compressor=lzo. It can also be changed at runtime using the sysfs "compressor" attribute, e.g.::

The default compressor is selected by the CONFIG_ZSWAP_COMPRESSOR_DEFAULT Kconfig option and can also be overridden by the compressor attribute at startup. For example, zswap.compressor = lzo. It can also be changed during operation by using the compressor sysfs attribute.

echo lzo > /sys/module/zswap/parameters/compressor

When the zpool and/or compressor parameter is changed at runtime, any existing compressed pages are not modified; they are left in their own zpool. When a request is made for a page in an old zpool, it is uncompressed using its original compressor. Once all pages are removed from an old zpool, the zpool and its compressor are freed.

If the zpool and / or compressor parameter changes at run time, the existing compressed pages will not change and will remain in their respective zpools. When the page generation is called from the old zpool, it will be expanded using the original compressor. Once all pages have been removed from the old zpool, the zpool and its compressor will be released.

Some of the pages in zswap are same-value filled pages (i.e. contents of the page have same value or repetitive pattern). These pages include zero-filled pages and they are handled differently. During store operation, a page is checked if it is a same-value filled page before compressing it. If true, the compressed length of the page is set to zero and the pattern or same-filled value is stored.

Some pages in zswap are pages filled with the same values (that is, the content of the pages has the same values or repeating patterns). These pages contain zero-filled pages and are handled differently. During store operations, pages are checked for the same value before being compressed. If true, the page compression length is set to zero and the pattern or the same fill value is saved.

Same-value filled pages identification feature is enabled by default and can be disabled at boot time by setting the same_filled_pages_enabled attribute to 0, e.g. zswap.same_filled_pages_enabled=0. It can also be enabled and disabled at runtime using the sysfs same_filled_pages_enabled attribute, e.g.::

The identification of pages filled with the same value is enabled by default and can be disabled by setting the same_filled_pages_enable * attribute to 0 at boot time, that is, zswap.same_filled_pages_enabled = 0. It can also be enabled / disabled at runtime using the sysfs attribute same_filled_pages_enabled *.

echo 1 > /sys/module/zswap/parameters/same_filled_pages_enabled

When zswap same-filled page identification is disabled at runtime, it will stop checking for the same-value filled pages during store operation. However, the existing pages which are marked as same-value filled pages remain stored unchanged in zswap until they are either loaded or invalidated.

If zswap padded pages with the same value are disabled at run time, the check for pages filled with the same value will stop during the store operation. However, existing pages marked as pages with the same value will be saved unchanged in zswap until they are loaded or disabled.

To prevent zswap from shrinking pool when zswap is full and there's a high pressure on swap (this will result in flipping pages in and out zswap pool without any real benefit but with a performance drop for the system), a special parameter has been introduced to implement a sort of hysteresis to refuse taking pages into zswap pool until it has sufficient space if the limit has been hit.

When zswap is full and under high swap pressure, don't make the pool small (that is, flipping and popping pages in zswap pool has no real benefit, but system performance (Decrease), special parameters have been introduced. For pages included in zswap pool, when the limit is reached, it does not fetch until sufficient space is secured, and realizes a kind of hysteresis.

To set the threshold at which zswap would start accepting pages again after it became full, use the sysfs accept_threhsold_percent attribute, e. g.::

Use the sysfs "accept_threhsold_percent" attribute to set a threshold to resume accepting pages after zswap is full. For example

echo 80 > /sys/module/zswap/parameters/accept_threhsold_percent

Setting this parameter to 100 will disable the hysteresis.

Hysteresis can be disabled by setting this setting to 100%.

A debugfs interface is provided for various statistic about pool size, number of pages stored, same-value filled pages and various counters for the reasons pages are rejected.

The debugfs interface provides different statistics about the pool size, the number of pages stored, the pages that meet the same value, and the different counters for why the pages are rejected.