Hi Dmitry - You are correct. The page scanner does not scan pages that are mapped to the kernel address space, and since the ZFS ARC is in the KAS, those pages will not be scanned (I can only assume they will not).
There are safeguards built into ZFS though - ZFS will monitor freemem and free pages from the ARC if memory is running low. I am not familiar with the specifics of the implementation, so am not able to tell you more about how it works at this time. If you run into a situation where you're running low on memory and ZFS ARC memory usage needs to be capped, there are ways to do that. Check out http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Limiting_the_ARC_Cache for specifics on how to do that (which varies depending on what Solaris release you're running). Thanks, /jim Degrave Dmitry wrote: > Thanks James, > > 'sr' will not be equal to zero, and anonymous page-ins and page-outs as > well, I see. Though several aspects are not clear for me. ZFS uses ARC, > and if I'm not mistaken, this means that level1&level2 page caches > (segmap and dynamic page cache for mmap'd files) become eliminated in > fact on the systems contain ZFS only. > > Before starting to save anonymous pages on disks, page scanner tries to > free pages used by page caches. This happens periodically even when we > are above lotsfree and the procedure keeps api/apo = 0 when we have > plenty of "free" phys memory (that is may be used by segmap for > example). > > With ZFS, file caches are moved to ARC, i.e. to kernel memory. In > pre-ZFS times, page scanner never scanned kernel memory. Is it still > correct now ? I.e. when ZFS module is loaded, page scanner still doesn't > scan ARC/kernel memory ? If so, we can face a situation when freemem is > below lotsfree and page scanner starts to save anon pages to disk. > > So, we may get sr and api/apo non zero when there are a lot of memory > that is used as file cache by ARC, and this will not mean a lack of phys > memory. > > Thanks, > Dmeetry >
