Writing back compressed pages [LWN.net]

Writing back compressed pages

Posted Feb 25, 2026 1:58 UTC (Wed) by intelfx (subscriber, #130118)
In reply to: Writing back compressed pages by PeeWee
Parent article: Modernizing swapping: virtual swap spaces

> 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.

to post comments

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.