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
freebsd-current@freebsd.org mailing list
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Reply via email to