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

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

The following reply was made to PR misc/60958; it has been noted by GNATS.

From: Ellie <el%horse64.org@localhost>
To: Taylor R Campbell <riastradh%NetBSD.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost
Subject: Re: misc/60958 ((Probaby) avoidable stability problems due to default
 memory management behavior on systems with a lot of RAM, ZFS, and no swap)
Date: Wed, 4 Nov 2026 01:38:33 +0000

 On 11/3/26 20:20, Taylor R Campbell wrote:
 > Which columns were you counting?
 > 
 > [...]
 
 It is increasingly clear to me now I might have counted the wrong ones, 
 and generally the numbers I gave are very confused.
 
 I apologize!
 
 - The actually available memory seems to be around 10GB. I found this 
 out via userspace memtest: https://horse64.org/temp/memtest.png This 
 seems a bit regrettably low and explains why I run into OOMs relatively 
 fast.
 
 - Nevertheless, OOM seems to mean system lockup. This seems to be 
 reflected here as if this is common behavior for ZFS: 
 https://wiki.netbsd.org/zfs/#index5h1 "4GB systems are known to lock up."
 
 - I still feel like this would be improvable by stopping user space 
 programs early enough...? Via some earlyoom-like service.
 
 > 
 > FYI, you should expect to only rarely have substantial amounts of
 > `Free' memory in top(1) -- e.g., shortly after memory-intensive
 > processes have exited or large cached files have been deleted, but
 > before the pages have been reused to cache file data.
 > 
 
 Seems like for me the free amount is typically 4+ digits megabytes.
 
 Once the "free" goes below 4 digits, eventually things seem to South.
 
 But I wouldn't know how to interpret this number well, clearly.
 
 > [...]> 
 > You don't need to interact with the login process.  The logic of
 > switching virtual terminals mostly happens in the kernel, and the
 > logic of entering ddb with C-A-ESC is entirely in the kernel.
 
 I did try this now, after running out of the 10GB again and having X 
 crash or get killed:
 
 Sadly, it didn't work. I was staring at the X startup messages, shown to 
 me after X quit, but with no prompt. Nothing happened when pressing any 
 of CTRL+ALT+Escape or CTRL+ALT+F1. I tried multiple times.
 
 
 
 Sorry again for my previous emails containing a lot of unconfirmed and 
 in many parts wrong numbers. I still hope that it inspires some ideas.
 
 Regards,
 
 Ellie