misc/60958: (Probaby) avoidable stability problems due to default memory management behavior on systems with a lot of RAM, ZFS, and no swap

["el%horse64.org@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60958
>Category:       misc
>Synopsis:       (Probaby) avoidable stability problems due to default memory management behavior on systems with a lot of RAM, ZFS, and no swap
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    misc-bug-people
>State:          open
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Tue Nov 03 17:30:01 +0000 2026
>Originator:     Ellie
>Release:        11.0
>Organization:
none, really!
>Environment:
NetBSD ruby-b-s-delly 11.0_STABLE NetBSD 11.0_STABLE (GENERIC) #0: Fri Oct 30 19:02:53 UTC 2026  mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/amd64/compile/GENERIC amd64

>Description:
After some discussions in chat, I was encouraged to report that I'm running into (probaby) avoidable stability problems when using NetBSD as a desktop. And these seem to be due to default memory management behavior.

Preconditions for these issues:

- I'm testing this on a system with 32GB RAM.

- I don't have swap: based on my past usage of Linux, I assumed with that amount I wouldn't strictly speaking need swap. Since I like avoiding unnecessary SSD disk writes, I went without one. I also have an encrypted / and encrypted /home so I wrongly assumed a swap would also be unencrypted - that seems to be untrue for NetBSD, but I didn't know that yet.

- I'm also using ZFS for /home, inside a cgd volume.

- The main offender leading to chaos seems to be a moderately used firefox with less than 30 tabs.

So what happens under these conditions seems to be roughly these chain of events:

1. Firefox on NetBSD seems fundamentally unable to see its own memory usage. You can see this when you open up about:memory in Firefox, it lists a lot of warnings and error messages. Perhaps in part due to that, it keeps growing.

2. Many JS heavy websites seem to leak memory, or at least to generate so many garbage objects that browsers struggle to collect garbage after them.

3. With under 30 tabs and little interaction, if one of these tabs is e.g. Matrix Element or Discord, Firefox will continue to use more memory on NetBSD, including 30GB+ RAM and beyond.

4. When memory runs out for the first and second time, no kernel memory killer kicks in. Instead, ZFS evicts a lot of its cache, trying desperately to keep the system running.

5. Then, with memory in "top" still reported to not be fully used up, ZFS will evict so much of its own memory that it seems to start to break down. At this point, a lot of programs start to freeze, and it's impossible to launch any new programs. I had a root shell open, I typed "dmesg" and it just hung.

6. Memory continues to get used up and if anything is getting killed I would be flying blind, since tail -f /var/log/messages seems to get stuck too and I can't even invoke "dmesg" anymore. If the OOM killer ever does something, it's too late.

Sorry for the wall of text, and I hope you're having a nice day! NetBSD is cool.

Regards,

Ellie
>How-To-Repeat:
1. Install NetBSD desktop. Don't configure any swap partitions.

2. Launch X or Wayland or whatever you like.

3. Install and launch Firefox. Open up a bunch of tabs, make sure to include some heavy JS apps that deal with a continuous intake of data like Matrix's Element or Disord's web UI.

4. Now you just have to wait. It might take a few hours or even more than a day, depending on how much memory your system has.
>Fix:
There might be multiple relatively doable ways of handling this better:

- For example, there could be a configurable user space OOM daemon similar to https://gihtub.com/rfjakob/earlyoom which could have more easily configurable limits, or a list of preferred processes to kill (e.g. browser stuff) and a list of processes to avoid (X, etc.).

- Or the kernel OOM could be configured by default to trigger earlier on systems without swap.

- The OOM should also probably try to do something on systems that have plenty of RAM, let's say 4GB plus, once ZFS starts evicting things, which seems to be at less than 10% free. Because letting ZFS take the fall only tends to provoke other problems.

- But at the end of the day I'm probably not smart enough to suggest the best solution. But I hope you'll have some ideas.

I hope you'll feel inspired to look into some of these things, since I think it would make a huge difference for NetBSD desktop use.

(As a slight tangent, for example I first thought the kernel was freezing up due to other problems and had major stability issues due to some driver bug.

Only because I'm I guess a comparatively somewhat experienced Unix user, did I eventually track down after 10+ freezes what was even going on. Thanks to the #NetBSD chatters too, they are awesome! I could easily see other new users give up earlier.)