Re: port-amd64/54988: possible memory leaks/swap problems

[mlh%goathill.org@localhost (MLH)]

The following reply was made to PR port-amd64/54988; it has been noted by GNATS.

From: mlh%goathill.org@localhost (MLH)
To: gnats-bugs%netbsd.org@localhost
Cc: port-amd64-maintainer%netbsd.org@localhost, gnats-admin%netbsd.org@localhost, 
 netbsd-bugs%netbsd.org@localhost, mlh%goathill.org@localhost
Subject: Re: port-amd64/54988: possible memory leaks/swap problems
Date: Sat, 22 Feb 2020 10:40:11 -0500 (EST)

 MLH wrote:
 > From: mlh%goathill.org@localhost (MLH)
 > 
 >  Joerg Sonnenberger wrote:
 >  > On Thu, Feb 20, 2020 at 04:15:01AM +0000, MLH wrote:
 >  > >  
 >  > >  Any idea on what is preventing the memory from being released and
 >  > >  why it just locks up?
 >  > 
 >  > I don't know, I'm just saying that you are looking at the wrong pools.
 >  > Look for those with high Npage, those are actually big.
 >  
 >  The problem continues to appear to be a filesystem-related issue
 >  as I can do compute-bound jobs with no problem. Physical memory is
 >  recovered as it normally does with no issue. Large or intensive
 >  filesystem writes appear to cause the system to seize and it doesn't
 >  even appear to require physical memory to be exhausted as it just
 >  seized twice with vmstat showing over 2G of available physical
 >  memory, and physical memory isn't showing to be recovered after
 >  intensive fs writes when I stop it before the system seizes.
 >  
 >  Have any filesystem-related changes been done recently?
 
 Such as (from CHANGES) :
 
         uvm: More precisely track clean/dirty pages, and change how they are
                 indexed, speeding up fsync() on large files by orders of
                 magnitude.  Original work done by yamt@. [ad 20200115]
 
 as all was fine just before this change and then with kernels from
 the last of Jan on, I am seeing the problems.