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

[intelfx]

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.

Then you adjust the OOM killer score of that precious process so it won't be first in line to get killed.

Either way, killing some processes is obviously preferable to locking up the whole system in endless thrashing (which is equivalent to killing all processes).

[rogerx]

Somebody say they have 32GB for VIM? Well I have 64GB of DDR memory for VIM.

Thank God for this patch. Only ~10 years a little too late for my 2000-2010 old hardware. Must have been using God's time plan?

[pal666]

I fail to see how this hack is better than setting swappiness to 200 (which biases reclaim heavily towards swap instead of page cache eviction), page-cluster to 0 (no read-ahead), and using zram with zstd compression.

anything is better than wasting precious ram on zram

[pal666]

...plus, do you really want to be having swap on disk now that your PC probably has an SSD in it, which has a limited number of wear cycles?

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

[pal666]

wait a second, he says that to protect from thrashing you need to swap more? i.e. all those people disabling swap were wrong? what a surprise(not really)

[ssokolow]

He's using ram as compressed swap (zram), which is a best method to speed up the system. This is enabled in Fedora by default for example.
Tuning swappiness to 200 has also its effect, and this is stated in the article you've linked.
Sorry, but it seems that's you who don't understand the topic. Reread the article you've linked.

...plus, do you really want to be having swap on disk now that your PC probably has an SSD in it, which has a limited number of wear cycles?

[ssokolow]

Since when was low latency better than reaping a process?

According to the readme on GitHub "Losing one of many tabs is a better behaviour for the user than an unresponsive system."

I disagree. This essentially means that if is better to lose data than having to wait for it.

Funny enough, that's exactly how I have earlyoom configured. If the system hits 90% RAM utilization (just below where things started to thrash), go in with the expectation that it's some jerk website running something like React or Vue gobbling up more than its fair share of RAM and kill the relevant content process so I can restart it if/when I need it again, with it not yet having leaked its way so far up.

[FONT=monospace][COLOR=#000000]--prefer '(^|/)firefox .*-contentproc( |$)'[/COLOR][/FONT]

[Developer12]

>37 tabs

1141 tabs in brave right now, 16GB of ram :P

still, I'll be interested to see if this patchset helps with the 15 minute long hangs I get when I do occasionally step over the 130 MB line by accident

[waxhead]

You are not going to have much use for that tab anyway when each mouse move takes a few hours (if it ever comes back).

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.

[F.Ultra]

Since when was low latency better than reaping a process?

According to the readme on GitHub "Losing one of many tabs is a better behaviour for the user than an unresponsive system."

I disagree. This essentially means that if is better to lose data than having to wait for it.

You are not going to have much use for that tab anyway when each mouse move takes a few hours (if it ever comes back).