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

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

On Thu, 30 Jan 2020 22:15:01 +0000 (UTC)
Martin Husemann <martin%duskware.de@localhost> wrote:

> The following reply was made to PR kern/54908; it has been noted by
> GNATS.
> 
> From: Martin Husemann <martin%duskware.de@localhost>
> To: gnats-bugs%netbsd.org@localhost
> Cc: 
> Subject: Re: kern/54908: kernel semi-lock-up
> Date: Thu, 30 Jan 2020 23:11:02 +0100
> 
>  Here is info from the next hang.
>  
>  Martin
...
>  db{0}> call uvm_km_va_starved_p  
>  1
>  db{0}>   
>  

Hi,
that explains the looping the kmem arena is filled but why? Some new
allocations must have appeared then and nothing gets freed by the pool
drain calls, which are now indirectly done via the pooldrain thread.

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.

Whats the kmem size for that arch?

This draining could be done by waking the pooldrain thread directly
since it's introduction (I have an unfineshed patch for that)
But this shouldn't change anything about this problem but make
responsibilities between those threads more clear.

Lars