Sudden grow of memory in "Laundry" state

[Mark Johnston]

On Thu, Sep 27, 2018 at 04:04:15PM -0700, Robert wrote:
> Is there a way to force move pages back from laundry to Free or Inactive?

There's no real way to do that from outside of the application.  The
application itself can free anonymous memory by unmapping it.  It can
also force memory to be marked clean (thus moving it back to the
inactive queue) using madvise(MADV_FREE).  This will cause the memory's
contents to be discarded, though.

> Also, what's the best way to identify addresses of these pages and 
> "look" inside of them?

There's no convenient way to do that that I'm aware of.  On amd64, you
could in principle use kgdb to dump individual pages in the queue via
the direct map:

# kgdb82 -q                                      
Reading symbols from /boot/kernel/kernel...Reading symbols from /usr/lib/debug//boot/kernel/kernel.debug...done.
done.
sched_switch (td=0xfffff8002c560000, newtd=0xfffff800025ca000, flags=<optimized out>) at /home/mark/src/freebsd-dev/sys/kern/sched_ule.c:2112
2112                    cpuid = PCPU_GET(cpuid);
(kgdb) p vm_dom[0].vmd_pagequeues[2]
$1 = {
  pq_mutex = {
    lock_object = {
      lo_name = 0xffffffff80c34c0d "vm laundry pagequeue",
      lo_flags = 21168128,
      lo_data = 0,
      lo_witness = 0xfffff8041ed6cb00
    },
    mtx_lock = 0
  },
  pq_pl = {
    tqh_first = 0xfffff8040f9ef980,
    tqh_last = 0xfffff8041227f448
  },
  pq_cnt = 20087,
  pq_name = 0xffffffff80c34c0d "vm laundry pagequeue",
  pq_pdpages = 0
}
(kgdb) x/512gx vm_dom[0].vmd_pagequeues[2].pq_pl.tqh_first->phys_addr + (vm_offset_t)&dmapbase
0xfffff801aea00000:     0x0000000800000000      0x000000082298c400
0xfffff801aea00010:     0x00000009be801000      0x0000000000000006
...