Writing back compressed pages [LWN.net]

Writing back compressed pages

Posted Feb 24, 2026 14:21 UTC (Tue) by farnz (subscriber, #17727)
In reply to: Compression on the backing device? by PeeWee
Parent article: Modernizing swapping: virtual swap spaces

Reading this week's second half of the merge window article, I noticed this patch for zram to enable compressed page writeback.

That puts compressed pages on the actual backing device - pages first get "swapped" to zram, where they're compressed and placed in the zram memory pool. If the zram memory pool fills, the compressed pages in zram are written as-is to zram's writeback device (along with incompressible pages).

to post comments

Writing back compressed pages

Posted Feb 24, 2026 22:35 UTC (Tue) by PeeWee (subscriber, #175777) [Link]

But Zram writeback is not really automatic [PDF] (page 7) and least of all LRU-based, because all the swap subsystem sees is yet another swap space and all zram sees is yet another block. A low-cost polling approach, i.e. long(-ish) sleep intervals, might be too late to the party when sudden memory spikes happen. Maybe hacking something that monitors PSI (pressure stall info), but then you are already reinventing kernel wheels.

Writing back compressed pages

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

One thing just popped up in my head. Why not "unify" zram and tmpfs? Just make tmpfs zswappable. My last encounters with tmpfs and incompressible data on it has led me to the conclusion that it "bypasses" frontswap; my guess is that it's simply unaware of it, since it has seniority, by some margin. Because the data was incompressible, I was expecting lots and lots of reject_compress_fail pages being counted in the zswap stats - this was before I discovered the noswap mount option had been added to tmpfs -, but I didn't see any. Swap space was filling up, alright, but zswap never saw those pages, apparently.

I don't really see the appeal of zram as a general-purpose block device. I believe someone wanted a compressed tmpfs. And then they realized, by running mkswap on it, that one can get "compressed RAM" on the cheap. While that is not unreasonable, using it that way, has some side effects. For instance, one should not have real swap space - at lower pri, of course -, because of LRU inversions when the zram-swap is full. OK, those inversions are on the swap subsystem; they happen without the need for zram in the mix. For instance, I have 4G swap at pri=2 on an NVMe-SSD and an additional 16G at pri=1 on an SATA-SSD for when I really push things. Obviously, when the 4G are full, the much fresher pages go to the slower 16G space. It's all hypothetical now, mostly because I've enabled zswap, now. This is only meant to show, that LRU inversions are not an inherent swap-on-zram problem; they have been long before zram even existed.

I think, for the purposes of zram, plain tmpfs with a path through zswap would suffice, unless I am missing some real use cases that require the block layer. Think of it, folios read from zram need to be decompressed, so the reader can use them. That means that some pages exist in compressed and uncompressed form at the same time, wasting memory; or maybe they replace one another? Doesn't really matter. My point is that tmpfs was almost there but from the other direction; pages live uncompressed in the page cache until they get swapped out. Just make that swapping go through zswap and zram is obsolete. The added bonus being that hot pages, regardless if they are anonymous or tmpfs or whatever, naturally stay in the "hot" uncompressed region of RAM, and the rest get (z)swapped out, as per usual. Whereas with swap on zram, the pages are already considered cold. And other uses of zram cannot easily make use of swap, because that might just be the same device they are coming from; kernel say: reclaim pages from zram0, swap subsystem writes pages to swap0 which resides on zram0! And just like that, you ruptured the space-time-continuum, by letting Marty McFly prevent his father from getting together with his mother, or some such. ;)

And, of course, that zswap quirk, to require pre-allocating space, (almost) never to be touched, needs to be fixed. But, in my head at least, it could all be way simpler that way. I think the authors of these patches may suffer from tunnel vision, so I am just throwing this out there as food for thought.

Writing back compressed pages

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

> Just make tmpfs zswappable.

Tmpfs certainly is {,z}swappable. Perhaps your system was misconfigured.

> I don't really see the appeal of zram as a general-purpose block device. I believe someone wanted a compressed tmpfs. And then they realized, by running mkswap on it, that one can get "compressed RAM" on the cheap. While that is not unreasonable, using it that way, has some side effects.

Yes. Trying to pass zram as a swap device, IMO, is a pretty blatant abuse of mm that only flies because practical deployments rarely get to exercise the interesting corner cases (in addition to the priority inversion concerns that you mention). For one, the swap subsystem is not designed around fallibility of swap devices. What would happen, for instance, if you configure a zram device with a limit on physical RAM utilization which is subsequently hit before the declared logical capacity is used up (for example, due to the data being incompressible)? Your guess is as good as mine.

Writing back compressed pages

Posted Feb 25, 2026 4:12 UTC (Wed) by PeeWee (subscriber, #175777) [Link] (6 responses)

> Just make tmpfs zswappable.
Tmpfs certainly is {,z}swappable. Perhaps your system was misconfigured.

Are you absolutely positive? I do know that it's swappable - says so on the box -, that's why I had been using it. Not so sure about the zswappable part, though. As I said, i was expecting lots of rejected pages on occasions when I put lots of incompressible data on tmpfs, but they did not show in the respective zswap stat counters, all the while swap was filling, with said zswap counters barely changing.

Maybe it's a more recent change? I haven't followed any changes since I discovered the noswap mount option. Since my heavy tmpfs usage involves incompressible data exclusively, I now prefer capping the tmpfs size somewhere close to but below the physical RAM - was double that before - and have other pages zswapped in their place, when the need arises. Otherwise, it'd be reject_compress_fail galore for tmpfs pages, anyway, and I'd like to save as much I/O as possible from happening. I'll tolerate the odd rejected page, but not on the gigabyte order of magnitude, on top of the outcome being clear before zswap even tried. My use case is only slightly worse off for the limitation of available space.

Writing back compressed pages

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

> Are you absolutely positive?

Entirely.

> Maybe it's a more recent change?

Depends on how recent we are talking. Linux 5.10 old enough?

Writing back compressed pages

Posted Feb 25, 2026 6:05 UTC (Wed) by PeeWee (subscriber, #175777) [Link] (4 responses)

> Are you absolutely positive?
Entirely.

Found it:

		error = swap_writeout(folio, plug);
		if (error != AOP_WRITEPAGE_ACTIVATE) {
			/* folio has been unlocked */
			return error;
		}


		/*
		 * The intention here is to avoid holding on to the swap when
		 * zswap was unable to compress and unable to writeback; but
		 * it will be appropriate if other reactivate cases are added.
		 */

> Maybe it's a more recent change?
Depends on how recent we are talking. Linux 5.10 old enough?

That may very well be the case. I am running Ubuntu LTS which is not exactly bleeding edge.

Thanks for finally giving me a definitive answer to that question!

Writing back compressed pages

Posted Feb 25, 2026 9:31 UTC (Wed) by intelfx (subscriber, #130118) [Link] (3 responses)

It wasn't really "definitive", more like an upper bound that I could give relatively quickly... Tmpfs is zswappable at least up to Linux 4.9 (stretch); this was a good excuse to play around with a clustered Incus and imagebuilder but I won't bother checking further.

> I am running Ubuntu LTS which is not exactly bleeding edge.

So I'd say unless your Ubuntu LTS is like 14.04, you've just got it misconfigured somehow.

Writing back compressed pages

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

> So I'd say unless your Ubuntu LTS is like 14.04, you've just got it misconfigured somehow.

(That said, given that you say your workloads are incompressible, it's all purely academic anyway. Oh well, still an excuse to build some images.)

Writing back compressed pages

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

I've just realized that my memory might also be clouded by my tinkering with memory.zswap.writeback=0. But I am pretty certain I saw that behavior before that cgroup knob even existed. And there seem to have been problems with accounting & cgroup control. I don't know how relevant they would have been for this case, but there is a set of commits under that umbrella linked to from the kernelnewbies page for the v5.19 release. I found those by accident while researching when writeback disabling was introduced, to narrow the time frame.

Anyway, I am starting to feel like I am abusing this thread/forum, so I'll leave it at that. I am very grateful for all your input and effort! Now I can explore some more use cases I had ruled out before. And if, against expectations, I do see the erroneous behavior, I'll know for sure that it must be an error of some kind.

Writing back compressed pages

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

It wasn't really "definitive"

Oh, now I get it. The "definitive" was meant in reference to the question if tmpfs somehow bypasses zswap. It does not matter too much, when it was made zswappable.