Date: Fri, 4 Aug 2023 10:44:10 -0400 From: Mark Johnston <markj@freebsd.org> To: Shrikanth Kamath <shrikanth07@gmail.com> Cc: freebsd-hackers@freebsd.org Subject: Re: How to watch Active pagequeue transitions with DTrace in the vm layer Message-ID: <ZM0Out3kT1JdTP3J@nuc> In-Reply-To: <CAEOAkMV2YnkjMoJpwHotutyX8szeQNDqUBv0mt%2BJWybg5Ru6JA@mail.gmail.com> References: <CAEOAkMXQfAGJTozu98Te3RmMxH-i_q5e2MzQLHdDGPsfciGAbg@mail.gmail.com> <ZMvEZIa09GcxKO58@nuc> <CAEOAkMV2YnkjMoJpwHotutyX8szeQNDqUBv0mt%2BJWybg5Ru6JA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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".
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?ZM0Out3kT1JdTP3J>