Hacker News Reader

Comment by baq | Hacker News Reader

I low key hope the current DDR5 prices push them to drag the Linux memory and swap management into the 21st century, too, because hard locking on low memory got old a while ago

View on HN

It takes a solid 45 seconds for me to enable zram (compressed RAM as swap) on a fresh Arch install. I know that doesn't solve the issue for 99% of people who don't even know what zram is / have no idea how to do it / are trying to do it for the first time, but it would be pretty easy for someone to enable that in a distro. I wouldn't be shocked if it is already enabled by default in Ubuntu or Fedora.

that just pushes away the problem ,it doesn't solve it. I still hit that limit when i ran a big compile while some other programs were using a lot of memory.

Zram has been enabled on Fedora by default since 2020:

https://fedoraproject.org/wiki/Changes/SwapOnZRAM

Zswap is arguably better. It confers most of the benefits of zram swap, plus being able to evict to non-RAM if cache becomes more important or if the situation is dire. The only times I use zram are when all I have to work with for storage is MMC, which is too slow and fragile to be written to unless absolutely necessary.

what behavior would you like to see when primary memory is under extreme pressure?

See mac or windows: grow swap automatically up to some sane limit, show a warning, give user an option to kill stuff; on headless systems, kill stuff. Do not page out critical system processes like sshd or the compositor.

A hard lock which requires a reboot or god forbid power cycling is the worst possible outcome, literally anything else which doesn’t start a fire is an improvement TBH.

> A hard lock which requires a reboot or god forbid power cycling is the worst possible outcome

Hilariously this happens on windows too.

Actually everything you said windows and mac doesn't do they do, if you put on a ton a memory pressure the system becomes unresponsive and locks up...

I've OOMd on my mac several times, and it has never gone completely unresponsive.

You get an OOM dialog with a list of apps that you can have it kill.

I feel I just need to run a slightly too large LLM with too much context on a MBP, and it's enough to slow it down irreparably until it suddenly hard resets. Maybe the memory pressure it does that at is much higher though compared to Linux?

Same as Windows. Instead the system freezes.

I thought that was fixed after MGLRU.

I feel like all of the elements are there: zram, zswap, various packages that improve on default oom handling... maybe it's more about creating sane defaults that "just work" at this point?

I think it's more of a user space issue, that the UI doesn't degrade nicely. The kernel just defaults to a more server-oriented approach.

Reply on news.ycombinator.com