Compression on the backing device? [LWN.net]

Compression on the backing device?

Posted Feb 22, 2026 2:48 UTC (Sun) by cesarb (subscriber, #6266)
In reply to: Compression on the backing device? by PeeWee
Parent article: Modernizing swapping: virtual swap spaces

> Experience with transparent filesystem compression suggests performance gains for rather little CPU time, since the actual I/O is reduced by the compression ratio.

I don't think it would be worth it, at least for normal 4K pages, since AFAIK the unit of I/O in modern systems is also 4K; that is, even if you could compress a page's contents to a single byte, you'd still have to write a full 4K.

(IIRC, the transparent filesystem compression in btrfs works in blocks of 128K)

to post comments

Compression on the backing device?

Posted Feb 23, 2026 0:39 UTC (Mon) by PeeWee (subscriber, #175777) [Link]

I was thinking more towards mTHP which have a higher potential compression ratio. On x86_64 anonymous mTHP start at 16K (for completeness: shared memory mTHP start at 8K for some reason). Given that I see compression ratios >3 with plain 4K pages when using zstd, one compressed 16K mTHP might just fit inside a single 4K block, for example, but not more that two 4K blocks. That'd be a >100% increase in I/O throughput, on average.

Clustered pages for swap

Posted Feb 23, 2026 11:42 UTC (Mon) by farnz (subscriber, #17727) [Link]

The usual way round that is to not swap page-by-page, but to try and select groups of pages to swap together; this has other benefits (since you're paying one set of swap subsystem and I/O overheads per swap page group), but has to be balanced against paging out part of your working set.

This involves a certain amount of activity tracking - has the page been referenced recently? - but you can then do things like swapping in units of 16 pages (64 KiB) at a time most of the time, except when a range of pages contains a recently accessed page (where you switch to page-at-a-time to avoid problems). Complexity is traded off here; you spend more CPU time on which pages to swap, in return for doing less I/O while swapping and getting more clean pages each time you decide to swap at all.

Note that it's very rare for the system to only need one more clean page before it settles into a steady state, unless you've entered swap thrash anyway; in practice, you're going to be swapping out chunks of memory that aren't part of the working set if you're swapping at all.

There's also a related trick to consider; if you can mark pages that you've swapped out as "do not re-read from swap", you can write out 16 pages, mark 15 of them as clean, and remove one from RAM. Then, if the other 15 are read, you can avoid removing them from RAM, and if they're written, you can mark the swap page as "discard on decompression". This can be a win in some cases - e.g. if you turn 64 KiB of I/O into 32 KiB of I/O and have no more than 8 pages that you avoid removing from RAM, you win.