how to recycle Inact memory more aggressively?

Mark Johnston markj at freebsd.org
Mon Mar 14 01:48:08 UTC 2016


On Sun, Mar 13, 2016 at 06:33:46PM -0700, Adrian Chadd wrote:
> Hi,
> 
> I can reproduce this by doing a mkimage on a large destination file
> image. it looks like it causes all the desktop processes to get paged
> out whilst it's doing so, and then the whole UI freezes until it
> catches up.

mkimg(1) maps the destination file with MAP_NOSYNC, so if it's larger
than RAM, I think it'll basically force the pagedaemon to write out the
image as it tries to reclaim pages from the inactive queue. This can
cause stalls if the pagedaemon blocks waiting for some I/O to complete.
The user/alc/PQ_LAUNDRY branch helps alleviate this problem by using a
different thread to launder dirty pages. I use mkimg on various desktop
machines to build bhyve images and have noticed the problem you're
describing; PQ_LAUNDRY helps quite a bit in that case. But I don't know
why this would be a new problem.

> 
> I'll poke alc and others to see if I can figure out how to trace
> what's going on. eg, are we running out of free pages and instead of
> waiting, deciding we're okay just paging out binaries/libraries so we
> can issue more dirty write io..
> 
> 
> -a


More information about the freebsd-current mailing list