Re: How to watch Active pagequeue transitions with DTrace in the vm layer

On Fri, Aug 04, 2023 at 01:31:04AM -0700, Shrikanth Kamath wrote:
> Thanks and appreciate your response Mark, a follow up query, so the system
> was probably at some point in the state where there were no pages in the
> laundry or even had pages backed by swap (refer the top snapshot below) .
> The two heavy applications with 12G resident + Wired + Buf already caused
> the Free to drop close to the minimum threshold, any further memory demand
> would have the pages of these applications move to laundry or swap, then
> would transition to Inactive or Laundry, later when these pages were
> referenced back the pagedaemon would move them back to the Active? Is that
> a correct understanding?

If there is a shortage of free pages, the page daemon will scan the
inactive queue, trying to reclaim clean pages.  Dirty pages go into the
laundry; once the laundry is "large enough", the page daemon will clean
pages in the laundry by writing them to swap.

If, while scanning a page in the inactive or laundry queues, the
pagedaemon notices that the page had been accessed since it was last
visited (e.g., the "accessed" bit is set on a page table entry mapping
the page), the page daemon will generally move it to the active queue.
This happens lazily: if there is no demand for free pages, an accessed
page can stay in the inactive/laundry queues indefinitely.

> last pid: 20494;  load averages:  0.38,  0.73,  0.80  up 0+01:49:05
>  21:14:49
> Mem: 9439M Active, 3638M Inact, 2644M Wired, 888M Buf, 413M Free
> 
> Swap: 8192M Total, 8192M Free
> 
> PID USERNAME    THR PRI NICE   SIZE    RES STATE    C   TIME    WCPU
> COMMAND
> 12043 root          5  22    0  9069M  7752M kqread   2  49:37   6.25% app1
> 12051 root          1  20    0  2704M  1964M select   3   0:41   0.00% app2
> 
> So if I run DTrace probe on vm_page_enqueue I will probably see that
> pagedaemon might be the thread that moved all those pages to Active? Is
> there a way to associate these to the process which referenced these pages

The page daemon does not use vm_page_enqueue() to move pages back to the
active queue.  Instead, check the vmstat -s counter I had mentioned,
"pages reactivated by the page daemon".