Re: kern/54908: kernel semi-lock-up

[Lars Reichardt <lars%paradoxon.info@localhost>]

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

From: Lars Reichardt <lars%paradoxon.info@localhost>
To: Andrew Doran <ad%netbsd.org@localhost>
Cc: gnats-bugs%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, martin%NetBSD.org@localhost
Subject: Re: kern/54908: kernel semi-lock-up
Date: Sat, 1 Feb 2020 08:59:12 +0100

 On Fri, 31 Jan 2020 21:40:01 +0000 (UTC)
 Andrew Doran <ad%netbsd.org@localhost> wrote:
 
 > The following reply was made to PR kern/54908; it has been noted by
 > GNATS.
 > 
 > From: Andrew Doran <ad%netbsd.org@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc: 
 > Subject: Re: kern/54908: kernel semi-lock-up
 > Date: Fri, 31 Jan 2020 21:36:58 +0000
 > 
 >  On Fri, Jan 31, 2020 at 11:55:01AM +0000, Lars Reichardt wrote:
 >  
 >  >  Maybe the rdaix radixtree allocations and reducing the kmem sizes
 >  >  might have increased the memory footprint of the allocator just
 >  > enough to hit that wall.  
 >  
 >  It's possible.  I would be interested in buffer cache usage and
 > excluding memory leaks first.  "show all pools" would be useful here
 > but it produces a lot of output.
 >  
 >  Andrew
 >  
 
 Most pools allocate from the kmem arena the non exhaustive list of
 exceptions I remember are:
 - the buffer caches do have a special pool_allocator backend
 - execargs
 - uarea
 
 those named kva-XXXX can be ignored they are used for allocating
 virtual addresses within kmem.
 
 kva-04096 is most likely of interest as most pool allocations seem to
 have page_size sized poolpages and on systems with no direct map those
 allocations are done via that pool. 
 
 Martin gave it try with the kmem arena limit raised
 to 256mb but the system didn't boot which puzzels me as it seems to have
 2g kvm.
 The reason for this is 128M for kmem isn't much for 2g physical memory
 eg i386 raises this to about 320mb some others to 256mb.
 
 Lars