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

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

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