OOMA kill with vm.pfault_oom_attempts="-1" on RPi3 at r357147

[Mark Millard]

On 2020-Jan-27, at 11:07, bob prohaska <fbsd at www.zefox.net> wrote:

> The latest attempt at buildworld on a Pi3 with kernel and sources at
> r357147 stopped with an "out of swap" kill. The activity log reported,
> in the one second samples before, during and after the kill recorded:
> 
> procs     memory       page                      disks     faults       cpu
> . . .
> It looks as if the vm.pfault_oom_attempts="-1" no longer shuts OOMA off. 
> Is there another way to deal with the problem?

The OOM problem (even with both vm.pageout_oom_seq set large and
vm.pfault_oom_attempts="-1") is apparently not ARM specific and
not specific to <= 4GiBytes of RAM. See, for example,

https://lists.freebsd.org/pipermail/freebsd-current/2020-January/075186.html

for a 5 GiByte RAM, 4 core amd64 context running a i386 jail (so a
tier 1 context) using MAKE_JOBS_NUMBER=4. It also has ZFS in the
context but the ARC space was < 950mb and not much swap space used.
Page-out delay and the number of attempts to get free RAM to be
above the threshold do not seem to be driving this case or yours.

We are back in the context of the difficulty figuring out what
kind criteria is selecting to do such OOM kills --in order to
then figure out how to best deal with that additional criteria.

So far as I know, in the past progress was only made when someone
already knowledgable got involved in isolating what was happening
and how to control it.

Gathering evidence can still prove possibly useful, even if such
is true for what it takes to make progress this time. But there
is uncertainty for what range of evidence is appropriate to try
for.

> . . .

(I'll not mix in material for the various deadlock crashes, cpu
reset failures, and such that also seem to be going on for arm
currently. Those seem arm specific from what I've seen on the
lists.)

===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)