[prev in list] [next in list] [prev in thread] [next in thread]
List: freebsd-hackers
Subject: Re: How to watch Active pagequeue transitions with DTrace in the vm layer
From: Mark Johnston <markj () freebsd ! org>
Date: 2023-08-04 14:44:10
Message-ID: ZM0Out3kT1JdTP3J () nuc
[Download RAW message or body]
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".
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic