[Bug 280846] Low memory freezes / OOM: a thread waited too long to allocate a page

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280846

--- Comment #54 from Mark Millard <marklmi26-fbsd@yahoo.com> ---
I've finally tested the RPi5 with video. I've installed official
builds of:

xorg-minimal-7.5.2_3           X.Org minimal distribution metaport
xf86-video-scfb-0.0.7_2        X.Org syscons display driver
lxqt-2.0.0_1                   Meta-port for the LXQt Desktop

firefox-131.0_1,2              Web browser based on the browser portion of
Mozilla
gimp-2.10.38,2                 Meta-port for the Gimp

(Of course, lots more was also installed.)

Because there is a known crash-issue for firefox vs. aslr
on aarch64, I'm using:

# proccontrol -m aslr -s disable firefox

to run firefox.

The RPi5 has 8 GiBytes of RAM. I'm not activating swap.
My context does not have the accounting patches, so I'm
ignoring laundry but monitoring free via top. (My top
build is a personally patched variation.) The context
is UFS based, zfs.ko not loaded. main [so: 15].

Firefox with some https://www.homedepot.com tabs and a
gimp are running. A simple ssh session from another
computer is in use for monitoring from another room.

After everything was set up I saw the likes of 3571Mi
Free. But I'm leaving it idle, not using it.

In your context, is there a known way to get the OOM
problem with some programs running but with on
interactive use of the system once set up? Is there a
known time frame for such for seeing notable Free
decreases in your context?

After about 60 min: 3452Mi Free, so about 119 MiByte
drop in an hour but I've no clue if such a rate will
be sustained.

-- 
You are receiving this mail because:
You are the assignee for the bug.