Date: Sun, 13 Mar 2016 19:08:31 -0700 From: Adrian Chadd <adrian.chadd@gmail.com> To: Mark Johnston <markj@freebsd.org> Cc: Gary Jennejohn <gljennjohn@gmail.com>, "current@freebsd.org" <current@freebsd.org> Subject: Re: how to recycle Inact memory more aggressively? Message-ID: <CAJ-VmonGrexLUvZkp8VCHuwt-B8Vg0P%2B7vV9XoHNRiT66W1Hfg@mail.gmail.com> In-Reply-To: <20160314015104.GB68039@wkstn-mjohnston.west.isilon.com> References: <20160312093835.727d7197@ernst.home> <20160314013319.GA68039@wkstn-mjohnston.west.isilon.com> <CAJ-Vmo=_iyCQkOtLpdbwu3qrEXOLs8fUMyme1o=_waYRiwwCSg@mail.gmail.com> <20160314015104.GB68039@wkstn-mjohnston.west.isilon.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13 March 2016 at 18:51, Mark Johnston <markj@freebsd.org> wrote: > 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. > That's why I'm confused. I just know that it didn't used to cause the whole UI to hang due to paging. -adrian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJ-VmonGrexLUvZkp8VCHuwt-B8Vg0P%2B7vV9XoHNRiT66W1Hfg>