From owner-svn-src-head@freebsd.org Fri Jul 10 18:55:03 2015 Return-Path: Delivered-To: svn-src-head@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3237997132; Fri, 10 Jul 2015 18:55:03 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 8E502856; Fri, 10 Jul 2015 18:55:03 +0000 (UTC) (envelope-from alc@rice.edu) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.15.0.59/8.15.0.59) with SMTP id t6AIsN7o008141; Fri, 10 Jul 2015 13:55:00 -0500 Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by pp2.rice.edu with ESMTP id 1vg4gt28c2-1; Fri, 10 Jul 2015 13:55:00 -0500 X-Virus-Scanned: by amavis-2.7.0 at mh1.mail.rice.edu, auth channel Received: from 108-254-203-201.lightspeed.hstntx.sbcglobal.net (108-254-203-201.lightspeed.hstntx.sbcglobal.net [108.254.203.201]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id 4DC6346023E; Fri, 10 Jul 2015 13:55:00 -0500 (CDT) Message-ID: <55A01503.20408@rice.edu> Date: Fri, 10 Jul 2015 13:54:59 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: hiren panchasara CC: Alan Cox , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r285282 - head/sys/vm References: <201507081746.t68Hk0To044278@repo.freebsd.org> <20150708182901.GJ51988@strugglingcoder.info> <20150710184917.GI87473@strugglingcoder.info> In-Reply-To: <20150710184917.GI87473@strugglingcoder.info> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=1 compositescore=0.9 suspectscore=10 malwarescore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=0 rbsscore=0.9 spamscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1506180000 definitions=main-1507100265 X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 18:55:04 -0000 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 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 >>