| 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. | |
| NOTE: Zswap is a new feature as of v3.11 and interacts heavily with memory | |
| reclaim. This interaction has not be 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 it 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.enabled=1 | |
| 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 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 | |
| return 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 | |
| tree nodes. | |
| 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. | |
| 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 | |
| controlled policies: | |
| * 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. | |
| zswap.compressor=deflate | |
| A debugfs interface is provided for various statistic about pool size, number | |
| of pages stored, and various counters for the reasons pages are rejected. |