Wacko kernel memory accounting in current/hppa

[Tom Lane <tgl%sss.pgh.pa.us@localhost>]

I've successfully gotten through a rather large test suite ---
Postgres buildfarm run, if you must know --- using NetBSD/hppa
built from yesterday's HEAD/202205210400Z snapshot.  (BTW,
that's a pretty impressive milestone considering I've never
been able to get any previous NetBSD release to even boot on
this 9000/C360 hardware.)

However, I observe completely wacko reports from top(1) and ps(1)
about the kernel's memory consumption.  With the machine sitting
idle post-run, top says

load averages:  0.00,  0.00,  0.00;               up 0+19:01:17        12:37:47
19 processes: 18 sleeping, 1 on CPU
CPU states:  0.0% user,  0.0% nice,  1.5% system,  0.0% interrupt, 98.5% idle
Memory: 38M Act, 4852K Inact, 26M Wired, 8456K Exec, 32M File, 296M Free
Swap: 1024M Total, 9068K Used, 1015M Free

  PID USERNAME PRI NICE   SIZE   RES STATE       TIME   WCPU    CPU COMMAND
    0 root     125    0     0K   79G vdrain     60:25  0.00%  0.00% [system]
 ...

"79G"?  This machine only has 512M RAM, plus the 1024M swap partition.
The "Memory:" line is less obviously implausible, but it's still not
right, because those numbers only sum to about 405M.

"ps auxww" seems to be looking at the same incorrect estimate, though
it presents it much differently:

USER        PID %CPU   %MEM   VSZ     RSS TTY   STAT STARTED     TIME COMMAND
root          0  0.0 15781.9     0 3050660 ?     DKl   5:37PM 60:26.58 [system]
...

... or wait, that %MEM estimate tracks pretty closely with 79G, but
that RSS value only means 3G doesn't it?

These numbers appear to have crept up slowly since boot but then
stabilized at what I'm showing here.  I'm guessing some sort of
pseudo-leak in memory accounting, but not actual memory consumption.
This test suite is extremely file-access-heavy, so something wrong in
vnode accounting could fit the facts perhaps.  The suite ran a good
deal slower than I was hoping for, almost double the time it takes
under HP-UX on the same hardware, so I'm wondering if this bogus
accounting is having real performance effects somewhere.

For comparison's sake I looked at a nearby machine running 9.2/amd64,
and there, top and ps agree that the kernel is using about 26M which
seems generally sane.

I wonder if anyone sees comparable follies elsewhere, or if this is
somehow hppa-specific.  Should I file a PR?

			regards, tom lane