I don’t use an OOM Killer. If by some terrible accident I get into a situation that I’m OOM (really unlikely, unless I run my program above), I just use the Magic SysRq button to gracefully reboot.
Constantly running a daemon that will save me from having to do so, perhaps once in several years, seems unnecessary. And even if the applications fail and OOM Killer kills them, I lose my work anyway, so the cost of rebooting is really low.
On a low memory computer, I would consider it. But even on my 5GB RAM laptop, I’ve never ever had an OOM situation, except when I did it on purpose to see what would happen. Maybe if I used Deepin
Earlyoom does not use echo f > /proc/sysrq-trigger because the Chrome people made their browser (and all electron-based apps - vscode, skype, discord etc) always be the first (innocent!) victim by setting oom_score_adj very high. Instead, earlyoom finds out itself by reading through /proc//status (actually /proc//statm, which contains the same information but is easier to parse programmatically).
Additionally, in recent kernels (tested on 4.0.5), triggering the kernel oom killer manually may not work at all. That is, it may only free some graphics memory (that will be allocated immediately again) and not actually kill any process. Here you can see how this looks like on my machine (Intel integrated graphics).
This? Some kind of limiter on my system? Oh right I’ll just go back to my old Macs or even consider heading down to my local supermarket and buying a new PC with Windows. This is like Norton AV, hyped up BS and not needed. Wake up and don’t believe the hype. FUD, it’s a friggin’ disease!
I have been setting it to 50% of RAM with a max of 8GB. By default the Fedora installer sets it to 100% of RAM with a max of 8GB.
I assume they are referring to 1GB of zram being fully utilized. If it isn’t in use it should take almost no space at all.
My thought process is that a kernel managed compressed ramdisk is still really fast so you are getting RAM expansion with only a small performance penalty when it is in use.
Right. This is actually a dualboot Arch-Fedora system and I’ve noticed that on Fedora side the zram is set to 100% of the RAM size.
I might be wrong but I read it as if 1 GB of zram would be equivalent of almost 3 GB of “regular” swap space? Am I wrong? I understand if it is not used for swapping then it should not take any memory space as it is dynamically allocated.
I read it the opposite way. 1GB of zram only takes 333MB of RAM.
I never looked into it enough to know if it was dynamically allocated or just fully compressed. I guess either way it amounts to more or less than the same thing.
Instead of swapping to disk, zram is swapping to RAM, but compressing (zipping) the data. So it uses your CPU to do the compressing, but writes nothing to disk.
If it is “dynamic” then why bother in the first place? Silly question probably but I am no Linux guru, I am just willing to learn. That we can learn and perhaps one day can I teach others.
What do you mean “why bother in the first place”? For the same reason why bother swapping.
There are two reasons to swap:
when the available memory gets low, to free it up, thus preventing an OOM situation
to put away rarely used pages to free up memory for more important stuff, thus increasing performance
Same thing with zram, except it does not swap to disk (because that is slow), but instead just compresses the less used memory contents to free up RAM for more important stuff. It works like a super fast swap (almost as fast as normal RAM access), but the price you pay is increased CPU usage.
Oh, now I am confused. I thought zram wont be taking any memory space at all before something is effectively swapped into it and then “1 GiB of swap uses only 333 MiB of RAM on average” That is if what would take 1 GB of space on a “regular” swap space, then it would take 333 MiB of memory space using zram.
OK so compression is involved. Got that, thanks. Minimal RAM but using compression and “un-compressing” involves using CPU and possibly GPU. It sounds to me like a dirty hack. Not really that impressed.
It isn’t really a hack, it is just swap on a compressed ramdisk that is efficiently managed. It only takes 5 minutes to activate. Why not try it and see if it hurts or helps your performance. If it doesn’t help you can disable it.
When I put it on my laptop with 8GB of ram I went from struggling to run a 2GB VM and my normal apps at the same time to being about to run a 4GB VM and my normal apps without any issues.
