

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.





















This is not a good thing btw. Any unused anonymous page takes up space that could instead be used for file-backed pages that make your system faster.
Swap is not tiered storage!
Priorities control order of preference, not tiers. If you run out of space on a higher priority, it will not move that swap’s data to a lower priority swap. It will keep all of it exactly where it is and new data will hit the lower prio swap instead, no matter how hot it is.
Cool tech but it’s dead and was quite niche even when it was alive.
Not a thing you actually want to use for swap. It’s not an automatic writeback that is integrated into the Linux MM in any way. (Probably has some use-case for non-swap zram purposes though.)
This makes no sense at all unless you are extremely space-constrained on the NVMe and absolutely must not OOM – even if progress stalls to an absolute crawl.
This is neither feasible nor desirable. You don’t have enough granularity to do anything useful by doing so.
Even if you had, it’d work against the MM because it resurrects pages as “hot” that have been cold for a long time.
In any situation where swap is important, making the kernel think cold pages are hot is the very last thing you want.
I too wish it were but tiered/transcedental memory is not a thing in Linux and these hacks do not change that fact; they merely look similar if you don’t look close enough.
I cannot think of a single use-case where this would be preferable to a decently sized physical swap with zswap XOR just zram swap (if physical swap is infeasible).