From owner-svn-src-all@FreeBSD.ORG Tue May 6 12:39:11 2014 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C2EFD211; Tue, 6 May 2014 12:39:11 +0000 (UTC) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) (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 97735646; Tue, 6 May 2014 12:39:11 +0000 (UTC) Received: from c-24-8-230-52.hsd1.co.comcast.net ([24.8.230.52] helo=damnhippie.dyndns.org) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WheeG-000MAP-GA; Tue, 06 May 2014 12:39:04 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by damnhippie.dyndns.org (8.14.3/8.14.3) with ESMTP id s46Cd1tw025582; Tue, 6 May 2014 06:39:01 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 24.8.230.52 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18ZaMM2m9y8j0qUbfuws9Tp Subject: Re: svn commit: r265418 - head/sys/vm From: Ian Lepore To: Alan Cox In-Reply-To: <201405060342.s463g5Fx047447@svn.freebsd.org> References: <201405060342.s463g5Fx047447@svn.freebsd.org> Content-Type: text/plain; charset="us-ascii" Date: Tue, 06 May 2014 06:39:01 -0600 Message-ID: <1399379941.22079.263.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 May 2014 12:39:11 -0000 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? -- Ian