LWN: Comments on "Compressed swap"

Compressed swap

nybble41 — Mon, 14 Apr 2014 22:36:15 +0000

> ... this would require some additional complexity in zswap to track which backing pages are actually available and which need to be paged in.

I agree that zswap would need to keep track of its pages. However, there shouldn't be any risk of accidentally triggering swapping. The compressed pages would only be read from swap at zswap's request.

> You might also have some terrible / recursive locking and code flow going on ...

I don't think so. The requests should be unidirectional, not recursive. The zswap RAM would be reserved and managed by zswap, not the pager. This assumes that zswap can access the swap interface directly the same way the pager does; if the pager and swap are tightly integrated then some refactoring would be in order.

Memory request -> no clean pages -> pager -> zswap -> write existing page directly to swap -> compress new page -> free source page -> resume thread.

Page fault -> pager -> zswap -> read compressed page back from swap into preallocated buffer -> decompress into target RAM -> resume thread.

Compressed swap

kmeyer — Mon, 14 Apr 2014 02:30:17 +0000

> The idea was that when frontswap hands a page to zswap and there isn't enough room for it in zswap's RAM, zswap picks one of its less-recently-used compressed pages and hands it off to the normal swap code, storing whatever token it gets back to identify the page for later retrieval.

Usually (I think) the page (a pointer in virtual memory) is unmapped from the page table and swapped out. Then when that pointer is accessed, a hardware fault occurs because the VMA is unmapped, and the kernel fault handler then brings back the page from swap.

> That frees up the page to store the new compressed data. Later, if and when frontswap asks for one of the old pages' data back, zswap can request the compressed page back from the normal swap subsystem and handle the request as it normally would.

So, the way this would actually be implemented (I think) is allowing pages in zswap's backing store to be swapped, but only when requested by zswap's front-end.

Because you don't want to accidentally access those backing pages and bring them back in and trigger more swapping elsewhere, this would require some additional complexity in zswap to track which backing pages are actually available and which need to be paged in.

You might also have some terrible / recursive locking and code flow going on between the memory request -> no clean pages -> need to swap a page -> pager <-> zswap <-> pager again(!); I'm unfamiliar with the area but it sounds like a nightmare (that zswap likely tries very hard to avoid right now with zbud).

It may be possible, but it would probably be a pain in the ass to implement and would have room for latent bugs.

Compressed swap

nybble41 — Fri, 28 Mar 2014 22:31:46 +0000

> it would need changes on the code which retrieves the pages from swap...
> you wouldn't be able to mix zswap and regular swap on the same system

Why is that? What I had in mind seemed fairly simple to integrate, though I'm not a Linux kernel developer and may be missing something. The idea was that when frontswap hands a page to zswap and there isn't enough room for it in zswap's RAM, zswap picks one of its less-recently-used compressed pages and hands it off to the normal swap code, storing whatever token it gets back to identify the page for later retrieval. That frees up the page to store the new compressed data. Later, if and when frontswap asks for one of the old pages' data back, zswap can request the compressed page back from the normal swap subsystem and handle the request as it normally would.

Compressed swap

gfa — Fri, 28 Mar 2014 20:05:01 +0000

> Hm, why cannot zswap write compressed pages on the disk avoiding the need for decompression?

while it would be **awesome** it would need changes on the code which retrieves the pages from swap, it would make zswap non-optional (at least runtime)
or at least you wouldn't be able to mix zswap and regular swap on the same system
unless you mark the compressed pages as compressed.

a simple solution would be run 2 swap devices one for compressed and other for non-compressed pages

Compressed swap

nybble41 — Thu, 27 Mar 2014 18:07:10 +0000

> Hm, why cannot zswap write compressed pages on the disk avoiding the need for decompression?

That was my thought as well. Instead of evicting (possibly multiple) compressed pages into uncompressed swap, why not just evict one of the pages holding compressed data instead? Besides avoiding decompression, you'd save swap space and I/O bandwidth, and avoid the issue of needing to write out several pages of previously compressed data to make room for a one new page.

Compressed swap

ibukanov — Thu, 27 Mar 2014 12:31:24 +0000

> That involves decompressing the data, then writing the resulting pages to the swap device. That can slow things down significantly.

Hm, why cannot zswap write compressed pages on the disk avoiding the need for decompression?

> The cost, of course, would be in the form of increased swap device I/O and space usage.

This is unacceptable if one uses cheap flash device as it introduces too much wear. The current implementation prevents that nicely.

> What the compressed swapping subsystems really need, he said, is better demonstration workloads.

From personal experience zram works very nicely on a chromebook allowing to run several Eclipse instances with multiple tabs opened in the browser on 2 GB machine with no swap. So I wonder why nobody at Google bothers to provide those workloads...