Comments (3)
  • Add a Comment
  • Edit
  • More Actions v
  • Quarantine this Entry

1 Oibaf commented Permalink

Interesting, but do you know zram ( https://code.google.com/p/compcache/ )? What differ zswap from the already merged zram?

2 RCJ commented Permalink

Oibaf, there are some notable differences.

 
zram:
- Status: In staging tree (as of 3.7) and looking to move into mainline
- Implementation: compressed block device, memory is dynamically allocated as data is stored
- Usage: Configure zram block device as a swap device to eliminate need for physical swap defice or swap file
- Benefits:
1. Eliminates need for physical swap device. This beame popular when netbooks first showed up. Zram (then compcache) allowed users to avoid swap shortening the lifespan of SSDs in these memory constrained systems.
2. A zram block device can be used for other applications other than swap, anything you might use a block device for conceivably.
- Drawbacks:
1. Zram's simple design means that the kernel swap path has no knowledge of zram; it just shows up as a regular swap device. If zram can not store the page it returns a write error to the swapper, and that swap slot will not be used in the future; this effectively shrinks the maximum capacity of the zram block device until the system is rebooted.
2. Once a page is stored in zram it will remain there until paged in or invalidated. The first pages to be paged out will be the oldest pages (LRU list), these are 'cold' pages that are infrequently access. As the system continues to swap it will move on to pages that are warmer (more frequently accessed), these may not be able to be stored because of the swap slots consumed by the cold pages. What zswap can not do (compcache had the option to configure a block backing device) is to evict pages out to physical disk. Ideally you want to age data out of the in-kernel compressed swap space out to disk so that you can use kernel memory for caching warm swap pages or free it for more productive use.
 
zswap:
- Status: Posted to LKML on Dec 11th, 2012
- Implementation: compressed in-kernel cache for swap pages. In-kernel cache is compressed, the compression algorithm is pluggable using the CryptoAPI and the storage for pages is dynamically allocated. Older pages can be evicted to disk making this a sort of write-behind cache.
- Usage: Cache swap pages destined for regular swap devices (or swap files).
- Benefits:
1. Integration with swap code (using Frontswap API) allows zswap to choose to store only pages that compress well and handle memory allocation failures, in those cases pages are sent to the backing swap device.
2. Oldest pages in the cache are pushed out to backing swap device to make room for newer pages, this solves the LRU inversion problem that a lack of page eviction would present.
- Drawbacks: Needs a physcial swap device (or swapfile).

3 RCJ commented Permalink

Strike that first issue on zram, failed writes to a swap device don't appear to invalidate the slot in the swap_map. (see end_swap_bio_write in mm/page_io.c)