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

[matthew green <mrg%eterna23.net@localhost>]

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

From: matthew green <mrg%eterna23.net@localhost>
To: Frank Kardel <kardel%netbsd.org@localhost>
Cc: kern-bug-people%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost,
    Chuck Silvers <chuq%chuq.com@localhost>, gnats-bugs%netbsd.org@localhost
Subject: re: kern/57558: pgdaemon 100% busy - no scanning (ZFS case)
Date: Sun, 05 May 2024 18:13:40 +1000

 just to clear up what i think is a confusion.
 
 > My comments to your remark below - a longer (re-)explaination follows =
 
 > after that.
 >
 > On 05/05/24 01:07, Chuck Silvers wrote:
 > > On Thu, May 02, 2024 at 08:50:02AM +0000, Frank Kardel wrote:
 > >>   Thus arc..c needs an additional check to determine needfree if the =
 kva
 > >>   free space falls below 10%.
 > > The intention is that 64-bit kernels should configure enough KVA
 > > to be able to map all of physical memory as kmem without running out o=
 f KVA.
 > We are not really running out of KVA, this is not violated. We are =
 
 > running into less than 10% free KVA available
 > and ZFS still allocating KVA while other pools give up KVA which gets =
 
 > allocated to ZFS UNTIL
 > we fall below uvmexp.freetarg.
 
 freetarg has nothing to do with KVA.  that's about free memory
 (actual physical pages).  KVA is a space that gets allocated out
 of, and sometimes that space has real pages backing it but not
 always (and sometimes the same page may be mapped more the once.)
 on 64-bit platforms, KVA is generally *huge*.
 
 KVA starvation shouldn't happen -- we have many terabytes
 available for the KVA on amd64, and pool reclaim only happens
 when we run low on free pages.  KVA on amd64 already is large
 enough to map all of physical memory in the 'direct map' region,
 as well as other places as needed.
 
 (it sounds like zfs needs to be able to reclaim pages like other
 consumers?)
 
 
 .mrg.