Date: Fri, 10 Jul 2015 13:54:59 -0500 From: Alan Cox <alc@rice.edu> To: hiren panchasara <hiren@FreeBSD.org> Cc: Alan Cox <alc@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r285282 - head/sys/vm Message-ID: <55A01503.20408@rice.edu> In-Reply-To: <20150710184917.GI87473@strugglingcoder.info> References: <201507081746.t68Hk0To044278@repo.freebsd.org> <20150708182901.GJ51988@strugglingcoder.info> <CC38576F-5B51-40A9-9895-2F8719AC6767@rice.edu> <20150710184917.GI87473@strugglingcoder.info>
next in thread | previous in thread | raw e-mail | index | archive | help
On 07/10/2015 13:49, hiren panchasara wrote: > On 07/09/15 at 06:13P, Alan Cox wrote: >> On Jul 8, 2015, at 1:29 PM, hiren panchasara <hiren@FreeBSD.org> wrote: >> >>> On 07/08/15 at 05:46P, Alan Cox wrote: >>>> Author: alc >>>> Date: Wed Jul 8 17:45:59 2015 >>>> New Revision: 285282 >>>> URL: https://svnweb.freebsd.org/changeset/base/285282 >>>> >>>> Log: >>>> The intention of r254304 was to scan the active queue continuously. >>>> However, I've observed the active queue scan stopping when there are >>>> frequent free page shortages and the inactive queue is steadily refilled >>>> by other mechanisms, such as the sequential access heuristic in vm_fault() >>>> or madvise(2). >>> What would be the actual downside/effect of this scenario? i.e. What goes >>> wrong when active queue scan stops and what would I see/observe on a >>> system when the problem is going on - is what I want to understand. >>> >> >> Basically, pages that haven?t been used recently get stuck in the active queue. Consequently, they are never reclaimed and repurposed to hold newly accessed data. Instead, more recently used pages from the inactive queue are reclaimed. Effectively, this reduces the amount of physical memory that is available for caching file data, and so the system (likely) performs more I/O operations than it would have with the stuck pages problem corrected. >> > Thanks. So it seems now there is an enforced number of min pages that > *must* be scanned which is proportional to the time of last scan. That is correct. >>>> To remedy this problem, record the time of the last active >>>> queue scan, and always scan a number of pages proportional to the time >>>> since the last scan, regardless of whether that last scan was a >>>> timeout-triggered ("pass == 0") or free-page-shortage-triggered ("pass > >>>> 0") scan. >>>> >>>> Also, on a timeout-triggered scan, allow a full scan of the active queue >>>> when the system is short of inactive pages. >>>> >>>> Reviewed by: kib >>>> MFC after: 6 weeks >>>> Sponsored by: EMC / Isilon Storage Division >>> [skip] >>> >>> Thanks in advance. >>> Cheers, >>> Hiren >>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?55A01503.20408>