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

NOTE: Zswap is a new feature as of v3.11 and interacts heavily with memoryreclaim. This interaction has not be fully explored on the large set ofpotential configurations and workloads that exist. For this reason, zswapis 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 swapdevice when the compressed pool reaches it size limit. This requirement hadbeen identified in prior community discussions.

To enabled zswap, the “enabled” attribute must be set to 1 at boot time. e.g.zswap.enabled=1

The first line of output from vmstat shows a summary since boot,
followed by the output over the last 3 seconds for each additional line.

The vmstat command reports the amount of swap space that is free (not reserved or allocated). This is the most useful measure.
Swap space is reserved first, then may be allocated. When a process requests memory via malloc() for example, the address space is created, but real pages are not allocated to it. At this point, swap space is reserved, but not allocated. The first time each page is accessed, a real page of memory is allocated to it and swap space is also allocated.

The vmstat paging counters provide us with some insight as to how busy VM system is, and if there are any memory resource issues.
The first thing to look for in the paging counters is the scan rate. The scan rate is the number of pages per second that the pageout scanner is scanning. If the scan rate is consistently zero, then the pageout scanner is not running, and there must be greater than lotsfree free memory. If the scan rate is zero, then there is no memory shortage. A non-zero scan rate does not always mean there is cause for concern. Remember that as reads and writes occur, pages are taken from the free list and eventually the amount of free memory will fall below lotsfree. In this case, the pageout scanner will be invoked to free up memory, hence a non-zero scan rate.