From owner-svn-src-head@FreeBSD.ORG Wed May 7 00:00:03 2014 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A35E1648; Wed, 7 May 2014 00:00:03 +0000 (UTC) Received: from pp2.rice.edu (proofpoint2.mail.rice.edu [128.42.201.101]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 68E823C9; Wed, 7 May 2014 00:00:03 +0000 (UTC) Received: from pps.filterd (pp2.rice.edu [127.0.0.1]) by pp2.rice.edu (8.14.5/8.14.5) with SMTP id s46NvrOO001803; Tue, 6 May 2014 19:00:01 -0500 Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by pp2.rice.edu with ESMTP id 1kq831g18v-1; Tue, 06 May 2014 19:00:01 -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 52342460110; Tue, 6 May 2014 19:00:00 -0500 (CDT) Message-ID: <5369777F.6010203@rice.edu> Date: Tue, 06 May 2014 18:59:59 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Ian Lepore , Alan Cox Subject: Re: svn commit: r265418 - head/sys/vm References: <201405060342.s463g5Fx047447@svn.freebsd.org> <1399379941.22079.263.camel@revolution.hippie.lan> In-Reply-To: <1399379941.22079.263.camel@revolution.hippie.lan> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 kscore.is_bulkscore=0 kscore.compositescore=0 circleOfTrustscore=0 compositescore=0.765433954564634 urlsuspect_oldscore=0.765433954564634 suspectscore=4 recipient_domain_to_sender_totalscore=0 phishscore=0 bulkscore=0 kscore.is_spamscore=1 recipient_to_sender_totalscore=0 recipient_domain_to_sender_domain_totalscore=0 rbsscore=0.765433954564634 spamscore=0 recipient_to_sender_domain_totalscore=0 urlsuspectscore=0.9 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1405060341 Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18 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: Wed, 07 May 2014 00:00:03 -0000 On 05/06/2014 07:39, Ian Lepore wrote: > On Tue, 2014-05-06 at 03:42 +0000, Alan Cox wrote: >> Author: alc >> Date: Tue May 6 03:42:04 2014 >> New Revision: 265418 >> URL: http://svnweb.freebsd.org/changeset/base/265418 >> >> Log: >> Prior to r254304, a separate function, vm_pageout_page_stats(), was used to >> periodically update the reference status of the active pages. This function >> was called, instead of vm_pageout_scan(), when memory was not scarce. The >> objective was to provide up to date reference status for active pages in >> case memory did become scarce and active pages needed to be deactivated. >> >> The active page queue scan performed by vm_pageout_page_stats() was >> virtually identical to that performed by vm_pageout_scan(), and so r254304 >> eliminated vm_pageout_page_stats(). Instead, vm_pageout_scan() is >> called with the parameter "pass" set to zero. The intention was that when >> pass is zero, vm_pageout_scan() would only scan the active queue. However, >> the variable page_shortage can still be greater than zero when memory is not >> scarce and vm_pageout_scan() is called with pass equal to zero. >> Consequently, the inactive queue may be scanned and dirty pages laundered >> even though that was not intended by r254304. This revision fixes that. >> >> Reported by: avg >> MFC after: 1 week >> Sponsored by: EMC / Isilon Storage Division >> >> Modified: >> head/sys/vm/vm_pageout.c >> >> Modified: head/sys/vm/vm_pageout.c >> ============================================================================== >> --- head/sys/vm/vm_pageout.c Tue May 6 03:38:04 2014 (r265417) >> +++ head/sys/vm/vm_pageout.c Tue May 6 03:42:04 2014 (r265418) >> @@ -942,13 +942,15 @@ vm_pageout_scan(struct vm_domain *vmd, i >> */ >> addl_page_shortage = 0; >> >> - deficit = atomic_readandclear_int(&vm_pageout_deficit); >> - >> /* >> * Calculate the number of pages we want to either free or move >> * to the cache. >> */ >> - page_shortage = vm_paging_target() + deficit; >> + if (pass > 0) { >> + deficit = atomic_readandclear_int(&vm_pageout_deficit); >> + page_shortage = vm_paging_target() + deficit; >> + } else >> + page_shortage = deficit = 0; >> >> /* >> * maxlaunder limits the number of dirty pages we flush per scan. >> > Does this address the observation that several folks have made on > current@ that pages are being pushed to swap much more agressively than > in the past, even when the system doesn't seem short of memory? > I hope so. Please let me know if you see any difference. I also suspect that another side-effect of r254304 is that we are swapping out idle processes sooner, before memory has become scarce. Has anyone observed this behavior? Alan