Date: Fri, 10 Jul 2015 11:49:17 -0700 From: hiren panchasara <hiren@FreeBSD.org> To: Alan Cox <alc@rice.edu> 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: <20150710184917.GI87473@strugglingcoder.info> In-Reply-To: <CC38576F-5B51-40A9-9895-2F8719AC6767@rice.edu> References: <201507081746.t68Hk0To044278@repo.freebsd.org> <20150708182901.GJ51988@strugglingcoder.info> <CC38576F-5B51-40A9-9895-2F8719AC6767@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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. Cheers, Hiren > > >> 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 > > [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQF8BAEBCgBmBQJVoBOsXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNEUyMEZBMUQ4Nzg4RjNGMTdFNjZGMDI4 QjkyNTBFMTU2M0VERkU1AAoJEIuSUOFWPt/lbXMIAJHYVah3TXApocr/nl+j2+oa mFUj9nJKY2nj4OT0HM7xYq0DJymp//3/NlCNcqSU0cSFzq9WyE2vYHgcpv4kQOmi N1rYeLWQKWHOpWwJ9NptnG1TJ0V1iHSpY5X60vpXP8pKivfaPgnBtv58U+Xi3UKu G5R1n4FkAIAgqQAqgfQQLg9Qf3HIGpE0CilmFo95pC28fbivClMOKuXsiEhHAt3O zP1Cdmbom6Xa9Kw2+SYtM9AtgDVG/54jnTNfHHu6CbFrIONkCkyivZKN0h4Sy0Ay TZtJxfV99dap2xfUvgFOa8hKHJs6nKjDSNJZedRfaFsvte/h1AjeXts+/gUf4Bg= =AYZb -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150710184917.GI87473>