|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.
|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.
|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.
|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.
|To enabled zswap, the "enabled" attribute must be set to 1 at boot time. e.g.
|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 makes use of zbud for the managing the compressed memory pool. Each
|allocation in zbud 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.
|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 zbud
|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
|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
|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.
|Zswap seeks to be simple in its policies. Sysfs attributes allow for one user
|* max_pool_percent - The maximum percentage of memory that the compressed
| pool can occupy.
|Zswap allows the compressor to be selected at kernel boot time by setting the
|“compressor” attribute. The default compressor is lzo. e.g.
|A debugfs interface is provided for various statistic about pool size, number
|of pages stored, and various counters for the reasons pages are rejected.