The graph is on a logarithmic scale btw
| Configuration | Before series (ms) | With series (ms) |
|---|---|---|
| 1 vCPU | 22.3 (21.6-22.6) | 0.97 (0.72-1.4) |
| 8 vCPUs | 314 (97-2542) | 7.0 (5.0-98) |
The graph is on a logarithmic scale btw
| Configuration | Before series (ms) | With series (ms) |
|---|---|---|
| 1 vCPU | 22.3 (21.6-22.6) | 0.97 (0.72-1.4) |
| 8 vCPUs | 314 (97-2542) | 7.0 (5.0-98) |
Well it could potentially reduce stutters in games when your RAM is full. I think most people don't use Zswap, but honestly they should! It's really good ( @victorz@lemmy.world wanted to know too)
Thanks. I'll read more about it, starting at https://wiki.archlinux.org/title/Zswap and https://en.wikipedia.org/wiki/Zswap (interestingly the Archwiki result was the top result). From Wikipedia:
Instead of moving memory pages to a swap device when they are to be swapped out, zswap compresses them and then stores them in a memory pool dynamically allocated in the system RAM. This way, writeback to the actual swap device is deferred or even completely avoided, resulting in a significantly reduced I/O load for systems that require swapping; the tradeoff is the need for additional CPU cycles to perform the compression.
To me, this sounds like its the opposite of full RAM. It tries to avoid writing to swap file, if I understand it correctly. Or bundle them up to write a huge chunk only once, like filesystem do on hard drives or SSDs in example, to reduce writing each single block. Do I understand it correctly? So one would need a huge amount of system RAM to have this work effectively. I have 32gb RAM and practically never fill it up when playing a game, usually. So maybe its worth exploring this option. Overall seems like most people with their current setup aren't affected by this Linux update.
So it basically makes a fake swap space in your RAM and that section is compressed. Linux still treats it as swap space so it only writes to it when you're low on RAM (or there's better things that could be cached in RAM even when it looks like your RAM is mostly empty it can still cache frequently accessed data from your disk). Zswap tries to store most swap in the compressed section of RAM, but when something doesn't compress well or when there's just too much stuff for RAM, it will write to the swap on disk.
So one would need a huge amount of system RAM to have this work effectively.
No, it's good for all sizes of RAM. If you have really small RAM, Zswap can actually be essential because without it you would be reading/writing to disk swap too much and performance would suffer. Someone got Linux running on a Switch Lite, just 4GB of RAM with full desktop and Steam too, and they said "With only 4 GB of RAM, zswap is basically mandatory here"
I have 32gb RAM and practically never fill it up when playing a game, usually.
Zswap would probably still improve performance for you, but it might not be a noticeable difference. But it will reduce your SSD writes, so that's nice to improve SSD lifetime a bit.
This is a very technical article about zRAM and Zswap https://chrisdown.name/... (I think his tone is overly harsh on zRAM, zRAM can be great if the computer has a slow spinning rust hard drive)
a little less technical https://easylinuxtipsproject.blogspot.com/...
Thanks that is a bit more enlightening. I'll read the given link and other source today, to get more into. Especially if it helps avoiding writes to SSD, as I got burned very hard from wearing down SSD (it was a software bug that lead to it). I guess the performance difference and the amount it saves from SSD rewrites shouldn't be too much to be worried about, but it bugged me so much that I will take this into consideration nonetheless.
Guess I learned something new today. :-)
But it will reduce your SSD writes, so that's nice to improve SSD lifetime a bit.
This, assuming you have a swap partition, right? I'm running with 64 GB without any swap. No issues while gaming AAA titles. Without swap there should be no wear on the SSD, right?
I find it slightly counterproductive that this is a countermeasure against swapping to disk/"device":
You want to avoid swapping, which happens when RAM is full (right?), so you create a really fast operating swap thing in RAM, reducing the amount of operational RAM, thus inducing more swapping because there's "less" "RAM".
Not to mention that the data is just moving from place to place inside RAM, just as it would've been sitting there before anyway. The only difference is the compression, I assume? Which is the main benefit? Otherwise it just feels like unnecessary shuffling of data back and forth.
In terms of performance, you actually don't want to avoid swapping, you want your OS to be smart about swapping. Some type of swap space is probably always beneficial unless you have more RAM than storage lol. Swap is great for putting aside data that isn't needed but can't be freed, and prioritizing filesystem cache over some background service that isn't doing anything. Even big servers often use some form of swap because swap can reduce disk reading. In some cases swap can even reduce disk writing, as counter intuitive as that sounds.
Yea both zRAM and Zswap use good compression, typically around 3:1 ratio, and it's still light on CPU usage, much faster than SSD swap.
That's not how it works but yes, if you don't need to swap, then that is better. Avoiding swapping though is also the wrong angle as depending on amount of ram, swapping can be beneficial, it just depends.
To me the compression sounds like it would increase RAM (virtually speaking), without hitting performance too much. Otherwise it would use the SSD and io is generally much slower than RAM operations (and compression, decompression in memory only if its fast like this one). When I understand the benefit correctly.
Nice.
My machine has only 8gb of ram. Since I use a lot of Gmail, chrome and other tabs (WhatsApp, Google messages) I often ended up swapping and getting really bogged.
With zram, all the code on those tabs is usually quite squash able, so rather than the delay of swapping to SSD, it swaps into 'compressed ram'.
Sure it's not great, but my computer is more stable with 4g zram than with 8g and real swap. 
Amazing! My 2 GB phone would have really benefited from this in running a webshit browser. If only Android wasn't a piece of shit to build and actually followed Linux development sometimes. But then it probably also wouldn't have any issues at all with 2 gigs, that or the browser would get bloat enough for this to be an issue again.
i use zram on a 3.x kernel on my ancient android phone. it helps significantly! modern firefox is unusable without zram.
Yes, but did you back port the patches mentioned and then suffer through the Android build system? Also, what architecture, version, swappiness and specs and stuff? Do you have anything else running (Termux with Tor or Orbot, Conversations, Signal/Molly...) or is it all killed immediatelly?
armv7 needs sligthly less RAM on average (so a 2GB 32-bit phone is more sufferable with Firefox) but running individual 32 bit processes on 64 bit userland is less efficient due to really fat shared libraries that now have to be duplicated, which is why some really crappy modern phone manufacturers (ahem, Samsung) decided to do the unimaginable and build an armv7 kernel with the whole non-free vendor partition shebang for a modern armv8.x/armv9.x CPU.
no i just meant i'm using zram function already available.. haven't improved it or anything. so my comment was kinda offtopic for this thread..
i have two android devices that i use zram on. one is a armv7 msm8974 phone with 2gb ram on android 8.1 (LG G2), the other is an arm64 sdm429 tablet also with 2gb ram on android 11 (Samsung Galaxy Tab A 8.0 2019). i frequently run termux and firefox/kiwibrowser together.
btw this Galaxy Tab A i have is one of those devices where the manufacturer decided to include armv7 kernel on a 64bit device. thankfully the bootloader is 64bit capable, and even the stock rom in one specific region is in 64bit, so i'm able to use 64bit in mine.
the android build system is actually not necessary to modify the android kernel. the kernel zImage/Image.gz can be built by simply getting the android toolchain (arm-eabi-4.9 for me) and compiling the kernel thru linux standard process (export ARCH=arm; export CROSS_COMPILE; make defconfig; make) and manually replacing the kernel in boot.img using unpackbootimg and mkbootimg.
Android 16 pre-redesign on LineageOS; 1.5GiB zram, 1.78GiB real RAM, swappiness 100 (I don't remember how I set that but unironically best swappiness value). Firefox kills everything else. Sometimes itself. Tried disk swap, hangs for 2 minutes and instead of killing Firefox or something else; it has a half chance of either loading fine eventually OR killing something else important enough for it to start again from bootanim.zip or whatever it was called.
This is the third time I hopped onto Jerboa to report on the numbers btw, shorter reply each time.
There was a comment somewhere from me about the build system, in short building manually for a 1 line diff made the kernel useless and I had to fuck with my computer a bit for it to allocate like 5x more RAM than it actually had for the build system to start up for like half an hour; then build the kernel in 4 minutes with a quarter of my RAM.
@programming.dev
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
go to feed...
@programming.dev
A community for everything relating to the GNU/Linux operating system (except the memes!)
Also, check out:
Original icon base courtesy of lewing@isc.tamu.edu and The GIMP
go to feed...
How does this affect us in real world usage? I know "lower number is better", but I have no understanding how this affects. I don't understand what exactly is measured here. Could someone explain it to me? Is this the read and write time of each file / block? I think with a huge enough system RAM, the swap file wouldn't be used much anyway, so there shouldn't be much of improvement for most people.
Could someone help me to understand this?
save