svn commit: r285282 - head/sys/vm

[Alan Cox]

On Jul 8, 2015, at 1:29 PM, hiren panchasara <hiren at 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.


>>  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