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: Martin Husemann <martin%duskware.de@localhost>
Cc: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost
Subject: Re: kern/54908: kernel semi-lock-up
Date: Fri, 31 Jan 2020 12:53:42 +0100

 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