"le9" Strives To Make Linux Very Usable On Systems With Small Amounts Of RAM

[F.Ultra]

Really?... it all depends on the content of that tab/program. Not everything happens inside a browser you know - sometimes you need to save things as well.

Yes really, a constant complaint here is that once their system starts to stall due to low memory then the entire system freezes for sometimes hours on end and sometimes without any possibility of escape. Aka the promised improvement of this patch is that instead of having your whole machine locked up (at which point you no longer can save the data in your tab anyway) vs loosing that tab.

Then there is the discussion if there should be a SIGOOM sent to all applications when the kernel enters a low memory situation so that they could free all their internal caches to help alleviate the situation.

However to be completely honest I think that we are all basically doing computers completely wrong, no single application should have a "save" function, instead every single change that you have made to a document should be saved instantly in a redo queue so that no matter when you yank out your power cord every single change up to the last ms (let's be reasonable after all) should be preserved with full redo/undo. And this should have been the norm since we switched from using floppies to hard drives.

[LinAGKar]

However to be completely honest I think that we are all basically doing computers completely wrong, no single application should have a "save" function, instead every single change that you have made to a document should be saved instantly in a redo queue so that no matter when you yank out your power cord every single change up to the last ms (let's be reasonable after all) should be preserved with full redo/undo. And this should have been the norm since we switched from using floppies to hard drives.

Redis AOF for everything?

[ssokolow]

However to be completely honest I think that we are all basically doing computers completely wrong, no single application should have a "save" function, instead every single change that you have made to a document should be saved instantly in a redo queue so that no matter when you yank out your power cord every single change up to the last ms (let's be reasonable after all) should be preserved with full redo/undo. And this should have been the norm since we switched from using floppies to hard drives.

As long as you implement an OS/platform-level analogue to Private Browsing Mode so I don't have to wind up using Firejail or Flatpak or something like that just to ensure I can get plug-pull erasure when I want it.

[ssokolow]

Yes, the wear capacity of modern (good quality) SSDs is obscenely large anyway, the drive will be morally obsolete long before you wear it out even with constant swapping.

When I got an SSD, one 1TB SSD and a heterogeneous pair of 10TB NAS HDDs replaced a JBOD where the oldest drives were 12 years old... I'd rather not waste cycles I can instead use for aggressively fsyncing data meant to be persistent. (Well, technically, the 2TB USB3 drive from the JBOD is still in use as a third nightly replica of the SSD's contents.)

...especially when 16GB of RAM + zram perfectly meets my needs 98% of the time, and I'm just about to upgrade to 32GB to cover the other 1.99% of the time. (earlyoom covers the remaining 0.01% whenever I screw up something I'm coding so badly that I create a memory-leak bomb.)

[ssokolow]

it would be stupid to not use ssd for most demanding work, wouldn't it?

...or you could just buy a screwdriver and use the butter knife for what it's designed for.

[Turbine]

16gb of ram isn't enough these days. I had to downgrade from 32gb of ram to 16gb and I kept running out of ram in Windows. Mind you I had the pagefile disabled. It wasn't very nice.

[arQon]

The problem is the depletion of the file cache. Protecting cache is proper solution.

I don't know enough to agree or disagree with that, but I don't think anyone sane can claim with a straight face that Linux's RAM-pressure handling isn't *absolutely @#$%ing terrible*. It's just STAGGERINGLY bad.

RAM exhaustion is never a good situation to end up in, but whatever the hell the kernel is currently doing is unquestionably not just "not the BEST option", it's not even a FUNCTIONAL one. At this point, it's hard to imagine that anything could actually make it worse, so anyone trying to tackle the problem who cares about the quality of their solution at all is likely to improve it, and quite likely to be able to do so by a significant amount.

Apparently that's now you, so, good luck to you, and thanks for putting some effort into a problem that desperately needs it.

[MastaG]

I've applied the le9db-5.10.patch to my 5.8.18 kernel.
I'm going to run this on Fedora on a 2GB ODroid board.
Fedora uses zram by default.

What should be sane values for CONFIG_CLEAN_LOW_KBYTES and CONFIG_CLEAN_MIN_KBYTES ?

[ValdikSS]

I've applied the le9db-5.10.patch to my 5.8.18 kernel.
I'm going to run this on Fedora on a 2GB ODroid board.
Fedora uses zram by default.

What should be sane values for CONFIG_CLEAN_LOW_KBYTES and CONFIG_CLEAN_MIN_KBYTES ?

try 300000 low, 0 min first.

[tedesign]

I tried the patch by installing the Linux Mint ISO that is on ValdikSS's website on a netbook-class laptop with 2 Gb of RAM (and a painfully slow hard drive) and couldn't believe my eyes. What was previously an unusable system when running a browser (in my case Firefox) is now apparently perfectly fine. I didn't open 37 tabs, but enough of them for casual, every day browsing and it kept going. As I'm not skilled enough in systems programming, can someone please explain to me what the catch is (if there's any one at all)? From what I think I've understood, the worst scenario you can expect is that the system will gracefully close random processes (in the browser's case the tabs), before it starts dumping in swap like mad and becoming completely unresponsive (and losing ALL the processes with a hard reboot). Is there any risk of memory corruption (other than what may happen to the shut-down user space processes) or other damage or risks at a system and file system level? If this is indeed the case, I really wonder why this approach and patch aren't immediately reviewed by the Linux Kernel Team and adopted, if found safe and secure. It seems like a complete no-brainer to me, especially given that this strategy has been (very honestly) originally credited to well-respected developers going back as early as 2010 (see the Github readme). Very well done and thank you Alexey Avramov for the code and ValdikSS for evangelizing and making the ISO available. PS are you completely sure that it is not worthwhile trying on 32-bit systems? I have an old Asus 32bit 900mhz 1GB eeePC that might rise from the ashes, perhaps with an even lighter DE than XFCE. Could this also apply to ARM boards (like the RPi or the BBB)? It would be awesome if you, ValdikSS, with your great clarity and when comfortable, would provide a step-by-step guide (including parameters optimization for the different architectures), to integrate this patch in any distribution and architecture one may need.