Compression on the backing device? [LWN.net]

Compression on the backing device?

Posted Feb 20, 2026 22:19 UTC (Fri) by PeeWee (subscriber, #175777)
In reply to: Compression on the backing device? by intelfx
Parent article: Modernizing swapping: virtual swap spaces

Conceptually it is still the same approach, is it not? The point is that one can't write back compressed folios. That makes LRU inversions upon hitting the zpool limit even worse, because they need to be decompressed before writeback while being passed left, right and center by rejected new ones. I think that was the impetus for proactive shrinking.

to post comments

Compression on the backing device?

Posted Feb 21, 2026 15:54 UTC (Sat) by intelfx (subscriber, #130118) [Link] (3 responses)

> Conceptually it is still the same approach, is it not? The point is <...>

It might be at the moment, but my point is that it is certainly not true that "due to its implementation details (frontswap), it cannot go further" as frontswap does not exist.

Compression on the backing device?

Posted Feb 24, 2026 23:15 UTC (Tue) by PeeWee (subscriber, #175777) [Link] (2 responses)

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 with noswap) 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.

Compression on the backing device?

Posted Feb 25, 2026 2:05 UTC (Wed) by intelfx (subscriber, #130118) [Link] (1 responses)

> Then why not let zswap assimilate the swap allocator, outright?

No objection from me.

Like I said several times already, I am merely remarking that while the present limitations of zswap may have _occurred_ due to it being originally a client of frontswap, nothing says it "cannot go further" than that. You have just suggested one way it, indeed, *can*.

Compression on the backing device?

Posted Feb 25, 2026 8:17 UTC (Wed) by PeeWee (subscriber, #175777) [Link]

Got ya. You were right, all along. And thanks for bringing me up to speed on that front (pun intended). ;)