Re: kern/57558: pgdaemon 100% busy - no scanning (ZFS case)

[Frank Kardel <kardel%netbsd.org@localhost>]

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

From: Frank Kardel <kardel%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/57558: pgdaemon 100% busy - no scanning (ZFS case)
Date: Thu, 3 Aug 2023 13:06:33 +0200

 Hi Taylor,
 
 I used the existing DTRACE knobs in arc.c (adding one for available 
 memory() thought, but fbt:return on
 
 arc_available_memory would suffice) and counter based
 
 event debugging (additional code) to track the tight loop in uvm_pdaemon.c.
 
 A sysctl for % KVA would be useful. the existing fbt and sdt probes already
 
 help a lot to track the pattern.
 
 In my setup (soon to be used for actual work) the loops could be reproduced.
 
 With patch 1 the pgdaemon loops went away KVA used fir ZFS was limited 
 to 75% but the
 
 cache was depleted because of missing patch 2. And patch 2 is needed as 
 there is no chance
 
 the pgdaemon will trigger a pool_drain unless we reach kva_starvation on 
 a non ZFS path.
 
 So what would the next steps be?
 
 Frank
 
 
 
 On 08/03/23 12:25, Taylor R Campbell wrote:
 > The following reply was made to PR kern/57558; it has been noted by GNATS.
 >
 > From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
 > To: kardel%NetBSD.org@localhost
 > Cc: gnats-bugs%NetBSD.org@localhost
 > Subject: Re: kern/57558: pgdaemon 100% busy - no scanning (ZFS case)
 > Date: Thu, 3 Aug 2023 10:23:19 +0000
 >
 >   Cool, thanks for looking into this!  I was planning to investigate at
 >   some point soon, starting by adding dtrace probes (and maybe wiring up
 >   the sysctl knobs) so we can reproduce the analysis of the issue in the
 >   field.  Your analysis sounds plausible, but I'd like to make sure we
 >   have the visibility to verify the behaviour -- and the change in
 >   behaviour -- first!
 >