Compression on the backing device?
Compression on the backing device?
Posted Feb 24, 2026 23:15 UTC (Tue) by PeeWee (subscriber, #175777)In reply to: Compression on the backing device? by intelfx
Parent article: Modernizing swapping: virtual swap spaces
So, Zswap essentially assimilated frontswap, because it was the only user left. But, unless that design changes, i.e. no longer fooling the rest of the kernel that its zpool contents resides on actual swap space, which is why the allocation happens before even touching the pages/folios in question, it can indeed not go further. From what I understand, this virtual swap space just takes the foolery one step further by also pretending that the space actually exists.
Then why not let zswap assimilate the swap allocator, outright? Then it'd only need to allocate on writeback, i.e. just in time, as plain old swap does; no need for virtual swap. And when writebacks are few and far between it's really not an issue to have decompression in that path. For instance, I currently have ~1G in a ~300M zpool, which are mostly cold and got zswapped on some memory spikes induced by my liberal use of tmpfs (mounted withnoswap) so something had to give. There was some to and fro, so I estimate that ~3G went through zswap and only ~5000 pages were reject_compress_fail - interestingly, I never see reject_compress_poor. And that's a cumulative counter that never decrements because zswap never sees those pages again - swap-in from the backing store is none of its concern; another quirk born from the "frontswap" design.
Also see the comment by Jonathan Corbet about the next iteration and the linked content, "ghost swap" in particular.