NetBSD-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-hppa/56849: Wacko kernel memory accounting in current/hppa
The following reply was made to PR port-hppa/56849; it has been noted by GNATS.
From: Tom Lane <tgl%sss.pgh.pa.us@localhost>
To: gnats-bugs%netbsd.org@localhost, Nick Hudson <nick.hudson%gmx.co.uk@localhost>
Cc: port-hppa-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
netbsd-bugs%netbsd.org@localhost
Subject: Re: port-hppa/56849: Wacko kernel memory accounting in current/hppa
Date: Tue, 24 May 2022 16:55:11 -0400
Nick Hudson <nick.hudson%gmx.co.uk@localhost> writes:
> Candidate fix...
I can confirm that with this patch installed, top and ps report a
reasonably stable kernel size, ranging from ~80M just after boot
to ~95M at peak load. This is a bit more than I was expecting, but
it's probably fine given that I kicked some things up after hitting
ENFILE errors:
$ cat /etc/sysctl.conf
...
# tgl additions
kern.ipc.semmni=3D100
kern.ipc.semmns=3D1000
kern.maxvnodes=3D50000
kern.maxproc=3D1000
kern.maxfiles=3D5000
I poked around with some of the other monitoring tools mentioned in
the NetBSD Guide, and I noticed that "sysstat bufcache" is a tad
confused about metadata buffers:
/0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10
Load Average |||||||||||||||||||||||||||||||||||||||||||||||
2144 metadata buffers using 98681168592896 kBytes of memo=
ry (19777529200%).
55451 pages for cached file data using 221804 kBytes of memory (44%)=
.
15502 pages for executables using 62008 kBytes of memory (12%)=
.
35216 pages for anon (non-file) data 140864 kBytes of memory (28%)=
.
495 free pages 1980 kBytes of memory ( 0%)=
.
File System Bufs used % kB in use % Bufsize kB % Util %
/home 1227 57 12852 0 12852 0 100
/usr 524 24 4460 0 4498 0 99
/var 36 1 226 0 226 0 100
/ 19 0 186 0 186 0 100
Total: 1806 84 17724 0 17762 0 100
error reading kmem for vaddr at 0xda030 (Bad address)
That error message at the bottom of the screen might or might not
be related to the silly stat. I'm not sure to what extent these
numbers should be expected to match what "top" shows, but they
don't seem crazy on their own with the exception of that one.
regards, tom lane
Home |
Main Index |
Thread Index |
Old Index