Date: Wed, 07 May 2014 07:05:16 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Alan Cox <alc@rice.edu> Cc: Alan Cox <alc@FreeBSD.org>, svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org Subject: Re: svn commit: r265418 - head/sys/vm Message-ID: <1399467916.22079.289.camel@revolution.hippie.lan> In-Reply-To: <5369777F.6010203@rice.edu> References: <201405060342.s463g5Fx047447@svn.freebsd.org> <1399379941.22079.263.camel@revolution.hippie.lan> <5369777F.6010203@rice.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2014-05-06 at 18:59 -0500, Alan Cox wrote: > 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 > I haven't seen the problem myself (I generally use option NO_SWAPPING on my ARM stuff), but there was some mailing-list talk about it. This is the main thread I was thinking of: http://lists.freebsd.org/pipermail/freebsd-stable/2014-April/078361.html I wonder if this one could be related too? http://lists.freebsd.org/pipermail/freebsd-stable/2014-January/077044.html -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1399467916.22079.289.camel>