Re: You're right, I was completely wrong and the freezes I'm seeing are... who even knows what

[Ellie <el%horse64.org@localhost>]

On 11/5/26 17:55, Greg Troxel wrote:
> However, calling mlock on even half of RAM is in my view abusive.
While that is fair, the lockups also happen regularly just out of the 
blue when there's a lot going on.

Maybe a system resource is running out and leading to some bug or lock 
or whatever handling that, but it's a completely unconfirmed guess.

Here's the resource limits I looked into:

- apparently there is some SHM mapping limit firefox might run into...? 
But the value it has by default is already higher than some random guide 
says firefox will typically need:

# sysctl kern.ipc.shmmaxpgs
kern.ipc.shmmaxpgs = 1828797

- total RAM was likely never reached, at least when I check "htop". I 
checked "top"'s free first but that apparently is a pretty meaningless 
number for that purpose. (I wouldn't know why exaclty.)

- I also raised the file descriptors to 4096 soft hard around 6k:

# ulimit -n
4096

... but then I watched the amount of file descriptors via a while shell 
loop that printed fstat | wc -l during one of those moments it froze and 
it wasn't even anywhere near the limit.


Anyway, I gotta admit I'm pretty unsure what to even try at this point.

I thought it was ZFS related, but now I don't know that either.

(I can't easily make it happen without ZFS since I only saw freezes 
while opening a ton of programs operating on my /home which is ZFS. Just 
making memtester ask for a big mlock alone won't do it.)

Regards,

Ellie

PS: This is a pretty standard install of NetBSD on x64 with encrypted 
disks I think, so I'm a bit surprised only I am seeing this. Did I do 
something weird by accident, without realizing? I have no idea.