Fedora 34 Looking To Tweak Default zRAM Configuration

[waxhead]

You do realise zswap decompresses the data before writing it to disk, don't you?

Actually no, I was not aware of that - thanks for educating me. On the other hand that is less important as long as decompression speed > disk speed while the MRU pages are still cached in memory and not pushed to physical swap.

[HyperDrive]

Actually no, I was not aware of that - thanks for educating me.

No worries, it's also a pet-peeve of mine. Zram with a backing dev also has the same problem. Data is always decompressed before being written out. The big issue is that nobody came up yet with a swap structure capable of storing compressed data.
Additionally, there's no multilevel swap awareness. Intuitively, compressed data should be moved in LRU fashion out of the compressed swap cache to a slower swap device in order to make room for new data, but I don't think anybody's working on this (the only time I saw this issue briefly mentioned was in the QA part of this presentation by Matthew Wilcox).

[karolherbst]

prime limitation of zram is it wastes precious ram on systems with insufficient ram, which is very stupid thing to do. real swap doesn't waste 25% or now 50% of memory

[ ] you unterstood what zwap is

[karolherbst]

seriously.. stop talking about stuff you have no clue of...

[pal666]

seriously.. stop talking about stuff you have no clue of...

[ ] you unterstood what zwap is

in a thread about zram, lol. do you understand that zram uses ram to store compressed pages? did you read subject article which quotes relevant piece?

[pal666]

On the other hand that is less important as long as decompression speed > disk speed while the MRU pages are still cached in memory and not pushed to physical swap.

i have radical new optimization idea: if you will not keep compressed pages in memory, you could in their place keep non-compressed pages which are not only cached in the sense "need decompression before any access(which will first require compression of something else to make up space)", but immediately accessible. yes you can put fewer non-compressed pages instead of compressed ones, but isn't "fewer usable" better than "more unusable"? (hint: the answer, as usual, is "it depends")

[waxhead]

i have radical new optimization idea: if you will not keep compressed pages in memory, you could in their place keep non-compressed pages which are not only cached in the sense "need decompression before any access(which will first require compression of something else to make up space)", but immediately accessible. yes you can put fewer non-compressed pages instead of compressed ones, but isn't "fewer usable" better than "more unusable"? (hint: the answer, as usual, is "it depends")

Well my develish little friend, it is all about utilizing memory for something useful. And you are right - it all depends on how much memory you have, how much you want to use for a specific purpose, or if half your memory was occupied by easily compressable data doesn't it? It also depend on which ass you like to stick your pitchfork in - you never know, compressing a ringbuffer might save you from an unpleasant experience, and as we all know if you drop your cache it might be a mess to reload it properly right?

[waxhead]

No worries, it's also a pet-peeve of mine. Zram with a backing dev also has the same problem. Data is always decompressed before being written out. The big issue is that nobody came up yet with a swap structure capable of storing compressed data.
Additionally, there's no multilevel swap awareness. Intuitively, compressed data should be moved in LRU fashion out of the compressed swap cache to a slower swap device in order to make room for new data, but I don't think anybody's working on this (the only time I saw this issue briefly mentioned was in the QA part of this presentation by Matthew Wilcox).

Out of curiosity - what do you mean about multilevel swap awareness? Localizing allocation of swap to NUMA nodes perhaps? And yes, from the little I know how Linux' swap function there is certainly room for improvement. The page replacement policy seems sane though so I guess you could get far with being able to add policy or weight (instead of priority) to swap devices. Weight plus an allocation policy based on percentage of free space and some nifty tricks to also take IO wait time into account could be quite useful. But we are not there yet

[HyperDrive]

Out of curiosity - what do you mean about multilevel swap awareness?

I mean having multiple swap devices prioritised by access time, not some arbitrary number. Right now, swap devices are used from the highest to the lowest priority (a lower priority device is only used if a higher priority one is full).
The idea would be, for example, if we had three swap devices (zram, SSD, spinning rust), to use the zram device until it filled up, then move the LRU compressed data to the SSD. When the SSD filled up, do the same from the SDD to the spinning rust, and so on.

[karolherbst]

in a thread about zram, lol. do you understand that zram uses ram to store compressed pages? did you read subject article which quotes relevant piece?

sorry for writing zswap instead of zram... same answer though. I am fully aware what both zswap and zram are, but you seem to not understand the fundamental concept here.