47
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 19 May 2026
47 points (100.0% liked)
Linux
65406 readers
413 users here now
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0
founded 7 years ago
MODERATORS
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.
All this talk just confirms my feelings that there is a general lack of understanding of actual modern workloads.
RAM (normal w/wo zram) doesn't get full, then stay full forever in real workloads. Not only is that not realistic at the "opened apps"/"running processes" level, it's not real at the heap allocation level within tasks within processes. And this is much more pronounced with code written in modern languages like Rust and some styles of C++. Modern heap allocators batch and cache (primarily to help with performance). But still, A LOT of memory is getting allocated and deallocated all the time, even from the kernel's PoV.
LRU itself is an imperfect approximation, not a goal. In the setup described in my other comment (fast SSD swap storages only used sparingly most of the time), so called LRU inversion gets auto-cancelled relatively quickly, as free space in RAM(+zram) gets available all the time, and some "LRU-hot" pages in SSD swap turn out to be actually cold, and those ones are the only ones that actually stay there.
This is why, I would imagine a lot of fake scenarios, and "benchmarks" based on them, may fail to replicate the practical reality of many (overall system) use-cases.
More tangentially, the oversized concern for file caching pages also points to specific aligned use-cases in mind, as if everyone is running DB-centric workloads or something.