Post #2729276

2026-05-20 20:56 UTC

In my testing, zram has much, much better compression than zswap. The points about LRU inversion, cgroups, and so on are valid, but at the end of the day, I don’t really care. I was able to open as many firefox tabs as I wanted with zram, but I could not do so with zswap, and that’s what matters to me. The author of a blogpost is a facebook engineer. Millions of ultra high performance Linux servers are a very different usecase than a single desktop. It’s perfectly reasonable for a solution for one to not be appropriate for the other. Copied from my previous comment about this where ISO also gave a similar reply and was met with a similar response lmao.

Replies (2)

@floquant@lemmy.dbzer0.com 2026-05-20 23:25

It’s not the opinion itself, it’s just the attitude. Your comment is a perfect example of what I consider a good reply as you brought both hard data and some nuance in expressing how you formed your opinion

Open ##2729275
@Atemu@lemmy.ml 2026-05-21 10:07

This testing compares apples to oranges. Differently sized swap and quite obviously different workloads. Given how very much compress ratios depend on the specific data that is compressed, this experimental setup cannot produce valid results. This is exacerbated by your swap being full. Zswap is more of a cache in front of your actual swap; it requires physical swap to function. If the physical swap is full, it cannot receive more data! Zswap not doing very much when the swap is full is totally expected behaviour because it simply doesn’t. The solution to that is to size your swap sensibly. (Admittedly, this does not appear to be documented clearly.) zswap uses the exact same allocator as zram these days (zsmalloc). It’d be very surprising if it had different space efficiency characteristics. It’s not impossible (could be a bug) but claiming so would require quite certain evidence IMHO. RE: LRU inversion: the problem with not caring about it is that it’s not a visible problem until it very suddenly is. Your system will not gradually degrade but very suddenly and unpredictably hit a wall that it cannot get itself over.

Open ##2736046