RE: Getting v_wire_count from a kernel core dump?

Ken Merry <ken_at_freebsd.org> wrote on
Date: Tue, 21 Mar 2023 15:11:30 UTC :


> I have kernel core dumps from several machines out in the field (customer sites) that were out of memory panics, and I’m trying to figure out, from the kernel core dumps, whether we’re dealing with a potential page leak.
> 
> For context, these machines are running stable/13 from April 2021, but they do have the fix for this bug:

Originally I was going to ask which message(s) were produced.
But then I noticed the mismatched time frame ("April 2021")
for the general vintage of the kernel involved vs. the modern
mnessaging.

QUOTE
author Mark Johnston <markj@FreeBSD.org> 2022-01-14 20:03:53 +0000
committer Mark Johnston <markj@FreeBSD.org> 2022-02-28 14:06:58 +0000
commit 13ba1d2836762d09f338158372806b90ce3d63ba (patch)
tree 5547db830727964bc7cb6c68a60fb062f85a5010 /sys/vm/vm_pageout.c
parent 19624b4c6b67881812e2bec0808a9d831cc61bb5 (diff)
download src-13ba1d2836762d09f338158372806b90ce3d63ba.tar.gz
src-13ba1d2836762d09f338158372806b90ce3d63ba.zip

vm_pageout: Print a more accurate message to the console before an OOM kill

Previously we'd always print "out of swap space." This can be misleading, as there are other reasons an OOM kill can be triggered. In particular, it's entirely possible to trigger an OOM kill on a system with plenty of free swap space.  
END QUOTE

The change leads to messages that look like:

pid . . .(?), jid . . ., uid . . ., was killed: failed to reclaim memory
pid . . .(?), jid . . ., uid . . ., was killed: a thread waited too long to allocate a page
pid . . .(?), jid . . ., uid . . ., was killed: out of swap space

Each of the 3 have rather different implications.

The last is actually a misnomer in that it really is one or
both of:

swap blk zone exhausted
swap pctrie zone exhausted

Those are kernel data structures, not directly swap space on
media.

You may want to pick up the messaging change.

===
Mark Millard
marklmi at yahoo.com