Re: kern/54818: 9.0_RC1 pagedaemon spins

[Havard Eidnes <he%NetBSD.org@localhost>]

The following reply was made to PR kern/54818; it has been noted by GNATS.

From: Havard Eidnes <he%NetBSD.org@localhost>
To: lars%paradoxon.info@localhost
Cc: gnats-bugs%netbsd.org@localhost, ad%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost, tsutsui%ceres.dti.ne.jp@localhost
Subject: Re: kern/54818: 9.0_RC1 pagedaemon spins
Date: Thu, 05 Mar 2020 16:41:39 +0100 (CET)

 >>   buf16k 16384 1411 0 1270 241 205 36 93 1 1 0
 >>   buf1k 1024 2 0 2 1 0 1 1 1 1 1
 >>   buf2k 2048 9 0 9 5 4 1 5 1 1 1
 >>   buf32k 32768 223292 0 193503 92993 73624 19369 37065 1 1 0
 >>   buf4k 4096 491370 0 391560 491371 391560 99811 179873 1 1 1
 >>   buf64k 65536 4 0 0 5 0 5 5 1 1 1
 >>   buf8k 8192 1865 0 1613 160 128 32 63 1 1 0
 >>   bufpl 288 210502 0 80506 15026 0 15026 15026 0 inf 111
 >
 >>>>> these are very interesting:
 >
 > These are the quantum caches for allocation virtual address space.
 >
 > No 4k allocation as the direct map is used (that's expected) and most
 > pools have a pool page size of 4k
 > but a lot of 64k allocations with the backing pool page size 256k.
 >
 > That is 64*63924 4091136kb worse of allocations
 > (15981 pool pages each 256k)
 >  and no releases at all seems like some leak to me.
 >
 > Does that happen when starting X?
 
 No.  It typically happens after a few days running.
 
 > Seems to be an intel drmkms judged from the list of pools.
 
 Correct:
 
 i915drmkms0 at pci0 dev 2 function 0: vendor 8086 product 0412 (rev. 0x06)
 drm: Memory usable by graphics device = 2048M
 drm: Supports vblank timestamp caching Rev 2 (21.10.2013).
 drm: Driver supports precise vblank timestamp query.
 i915drmkms0: interrupting at ioapic0 pin 16 (i915)
 intelfb0 at i915drmkms0
 i915drmkms0: info: registered panic notifier
 i915drmkms0: More than 8 outputs detected via ACPI
 intelfb0: framebuffer at 0xffff80013bc7d000, size 1920x1200, depth 32, stride 7680
 wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100 emulation)
 wsmux1: connecting to wsdisplay0
 
 > The kmem arena is most likely a bit more than this mentioned 4g as the
 > machine seems to have 16gb?
 
 Physical ram is 16GB, yes.
 
 > It should be the second entry of the output of "pmap 0".
 
 Currently the first three lines from "pmap 0" is
 
 FFFF800000000000 473672K read/write/exec     [ anon ]
 FFFF80001CE92000 4166220K read/write/exec     [ anon ]
 FFFF80011B325000 524288K read/write/exec     [ pager_map ]
 
 >>   kva-12288 12288 35 0 0 2 0 2 2 0 inf 0
 >>   kva-16384 16384 17 0 0 2 0 2 2 0 inf 0
 >>   kva-20480 20480 84 0 0 7 0 7 7 0 inf 0
 >>   kva-24576 24576 9 0 0 1 0 1 1 0 inf 0
 >>   kva-28672 28672 3 0 0 1 0 1 1 0 inf 0
 >>   kva-32768 32768 1 0 0 1 0 1 1 0 inf 0
 >>   kva-36864 36864 3 0 0 1 0 1 1 0 inf 0
 >>   kva-40960 40960 108 0 0 18 0 18 18 0 inf 0
 >>   kva-49152 49152 1 0 0 1 0 1 1 0 inf 0
 >>   kva-65536 65536 63924 0 0 15981 0 15981 15981 0 inf 0
 >>   kva-8192 8192 52 0 0 2 0 2 2 0 inf 0
 >
 > ...
 > I'm not aware of any pool that allocates from the 64k quantum cache so
 > it doesn't surprise me that that pagedaemon/pool_drain
 > isn't able to free anything.
 
 Hm.  I know too little about the mechanism, but having something
 allocate from it and nothing to release when there's pressure
 looks like a recipe for disaster.
 
 Regards,
 
 - Havard