Based on kernel version 3.19. Page generated on 2015-02-13 21:23 EST.
1 Overview: 2 3 Zswap is a lightweight compressed cache for swap pages. It takes pages that are 4 in the process of being swapped out and attempts to compress them into a 5 dynamically allocated RAM-based memory pool. zswap basically trades CPU cycles 6 for potentially reduced swap I/O. This trade-off can also result in a 7 significant performance improvement if reads from the compressed cache are 8 faster than reads from a swap device. 9 10 NOTE: Zswap is a new feature as of v3.11 and interacts heavily with memory 11 reclaim. This interaction has not been fully explored on the large set of 12 potential configurations and workloads that exist. For this reason, zswap 13 is a work in progress and should be considered experimental. 14 15 Some potential benefits: 16 * Desktop/laptop users with limited RAM capacities can mitigate the 17 performance impact of swapping. 18 * Overcommitted guests that share a common I/O resource can 19 dramatically reduce their swap I/O pressure, avoiding heavy handed I/O 20 throttling by the hypervisor. This allows more work to get done with less 21 impact to the guest workload and guests sharing the I/O subsystem 22 * Users with SSDs as swap devices can extend the life of the device by 23 drastically reducing life-shortening writes. 24 25 Zswap evicts pages from compressed cache on an LRU basis to the backing swap 26 device when the compressed pool reaches its size limit. This requirement had 27 been identified in prior community discussions. 28 29 To enabled zswap, the "enabled" attribute must be set to 1 at boot time. e.g. 30 zswap.enabled=1 31 32 Design: 33 34 Zswap receives pages for compression through the Frontswap API and is able to 35 evict pages from its own compressed pool on an LRU basis and write them back to 36 the backing swap device in the case that the compressed pool is full. 37 38 Zswap makes use of zbud for the managing the compressed memory pool. Each 39 allocation in zbud is not directly accessible by address. Rather, a handle is 40 returned by the allocation routine and that handle must be mapped before being 41 accessed. The compressed memory pool grows on demand and shrinks as compressed 42 pages are freed. The pool is not preallocated. 43 44 When a swap page is passed from frontswap to zswap, zswap maintains a mapping 45 of the swap entry, a combination of the swap type and swap offset, to the zbud 46 handle that references that compressed swap page. This mapping is achieved 47 with a red-black tree per swap type. The swap offset is the search key for the 48 tree nodes. 49 50 During a page fault on a PTE that is a swap entry, frontswap calls the zswap 51 load function to decompress the page into the page allocated by the page fault 52 handler. 53 54 Once there are no PTEs referencing a swap page stored in zswap (i.e. the count 55 in the swap_map goes to 0) the swap code calls the zswap invalidate function, 56 via frontswap, to free the compressed entry. 57 58 Zswap seeks to be simple in its policies. Sysfs attributes allow for one user 59 controlled policy: 60 * max_pool_percent - The maximum percentage of memory that the compressed 61 pool can occupy. 62 63 Zswap allows the compressor to be selected at kernel boot time by setting the 64 “compressor” attribute. The default compressor is lzo. e.g. 65 zswap.compressor=deflate 66 67 A debugfs interface is provided for various statistic about pool size, number 68 of pages stored, and various counters for the reasons pages are rejected.