Re: Increasing amount of cached (unflushed/un-invalidated) file pages causing kernel panics

[Alexander Schreiber <als%thangorodrim.ch@localhost>]

On Sun, Oct 31, 2021 at 09:41:42PM -0000, Michael van Elst wrote:
> 
> The expected behaviour is that the system gets very busy until
> enough memory is freed, then everything should work normally. This
> can take some time and the system may look stalled or frozen.

I've seen that when building memory hungry ports (e.g. rust) on the
Pinebook. Just 2G RAM, with another 4G swap to avoid OOMs. With single
cc processes eating > 1500M of RAM and free memory < 16M, the system
goes apparently catatonic for a while, with [system] eating 100% CPU
(and nothing else running), but eventually comes back to life. Might
take a bit, though. Parallely logged in ssh session took more than 30s
to respond (because they'd been paged out almost entirely and the kernel
needed to find enough memory to page enough of the process back in to
have it respond, I assume).

> There are also situations where the system may lock up. Either
> because page daemon heuristics are invalid (memory isn't freed
> although there is demand) or because free memory requires allocating
> memory (either buffers or some kernel structures) and that fails.
> Freeing memory by e.g. terminating a program or reducing the vnode
> cache then resolves the lock. This obviously shouldn't happen.

I've seen what I suspect was a lock up when swap was on NFS - but I might
have been too impatient to wait for the system to recover. Of course with
NFS swap, there is even more potential for fun in a pretty-much-out-of-memory
situation.

Kind regards,
           Alex.
-- 
"Opportunity is missed by most people because it is dressed in overalls and
 looks like work."                                      -- Thomas A. Edison