zswap.txt 5.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102
  1. Overview:
  2. Zswap is a lightweight compressed cache for swap pages. It takes pages that are
  3. in the process of being swapped out and attempts to compress them into a
  4. dynamically allocated RAM-based memory pool. zswap basically trades CPU cycles
  5. for potentially reduced swap I/O.  This trade-off can also result in a
  6. significant performance improvement if reads from the compressed cache are
  7. faster than reads from a swap device.
  8. NOTE: Zswap is a new feature as of v3.11 and interacts heavily with memory
  9. reclaim. This interaction has not been fully explored on the large set of
  10. potential configurations and workloads that exist. For this reason, zswap
  11. is a work in progress and should be considered experimental.
  12. Some potential benefits:
  13. * Desktop/laptop users with limited RAM capacities can mitigate the
  14.     performance impact of swapping.
  15. * Overcommitted guests that share a common I/O resource can
  16.     dramatically reduce their swap I/O pressure, avoiding heavy handed I/O
  17. throttling by the hypervisor. This allows more work to get done with less
  18. impact to the guest workload and guests sharing the I/O subsystem
  19. * Users with SSDs as swap devices can extend the life of the device by
  20.     drastically reducing life-shortening writes.
  21. Zswap evicts pages from compressed cache on an LRU basis to the backing swap
  22. device when the compressed pool reaches its size limit. This requirement had
  23. been identified in prior community discussions.
  24. Zswap is disabled by default but can be enabled at boot time by setting
  25. the "enabled" attribute to 1 at boot time. ie: zswap.enabled=1. Zswap
  26. can also be enabled and disabled at runtime using the sysfs interface.
  27. An example command to enable zswap at runtime, assuming sysfs is mounted
  28. at /sys, is:
  29. echo 1 > /sys/module/zswap/parameters/enabled
  30. When zswap is disabled at runtime it will stop storing pages that are
  31. being swapped out. However, it will _not_ immediately write out or fault
  32. back into memory all of the pages stored in the compressed pool. The
  33. pages stored in zswap will remain in the compressed pool until they are
  34. either invalidated or faulted back into memory. In order to force all
  35. pages out of the compressed pool, a swapoff on the swap device(s) will
  36. fault back into memory all swapped out pages, including those in the
  37. compressed pool.
  38. Design:
  39. Zswap receives pages for compression through the Frontswap API and is able to
  40. evict pages from its own compressed pool on an LRU basis and write them back to
  41. the backing swap device in the case that the compressed pool is full.
  42. Zswap makes use of zpool for the managing the compressed memory pool. Each
  43. allocation in zpool is not directly accessible by address. Rather, a handle is
  44. returned by the allocation routine and that handle must be mapped before being
  45. accessed. The compressed memory pool grows on demand and shrinks as compressed
  46. pages are freed. The pool is not preallocated. By default, a zpool of type
  47. zbud is created, but it can be selected at boot time by setting the "zpool"
  48. attribute, e.g. zswap.zpool=zbud. It can also be changed at runtime using the
  49. sysfs "zpool" attribute, e.g.
  50. echo zbud > /sys/module/zswap/parameters/zpool
  51. The zbud type zpool allocates exactly 1 page to store 2 compressed pages, which
  52. means the compression ratio will always be 2:1 or worse (because of half-full
  53. zbud pages). The zsmalloc type zpool has a more complex compressed page
  54. storage method, and it can achieve greater storage densities. However,
  55. zsmalloc does not implement compressed page eviction, so once zswap fills it
  56. cannot evict the oldest page, it can only reject new pages.
  57. When a swap page is passed from frontswap to zswap, zswap maintains a mapping
  58. of the swap entry, a combination of the swap type and swap offset, to the zpool
  59. handle that references that compressed swap page. This mapping is achieved
  60. with a red-black tree per swap type. The swap offset is the search key for the
  61. tree nodes.
  62. During a page fault on a PTE that is a swap entry, frontswap calls the zswap
  63. load function to decompress the page into the page allocated by the page fault
  64. handler.
  65. Once there are no PTEs referencing a swap page stored in zswap (i.e. the count
  66. in the swap_map goes to 0) the swap code calls the zswap invalidate function,
  67. via frontswap, to free the compressed entry.
  68. Zswap seeks to be simple in its policies. Sysfs attributes allow for one user
  69. controlled policy:
  70. * max_pool_percent - The maximum percentage of memory that the compressed
  71. pool can occupy.
  72. The default compressor is lzo, but it can be selected at boot time by setting
  73. the “compressor” attribute, e.g. zswap.compressor=lzo. It can also be changed
  74. at runtime using the sysfs "compressor" attribute, e.g.
  75. echo lzo > /sys/module/zswap/parameters/compressor
  76. When the zpool and/or compressor parameter is changed at runtime, any existing
  77. compressed pages are not modified; they are left in their own zpool. When a
  78. request is made for a page in an old zpool, it is uncompressed using its
  79. original compressor. Once all pages are removed from an old zpool, the zpool
  80. and its compressor are freed.
  81. A debugfs interface is provided for various statistic about pool size, number
  82. of pages stored, and various counters for the reasons pages are rejected.