From owner-freebsd-hackers@FreeBSD.ORG Sun Jul 25 10:07:27 2010 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 320CE1065673 for ; Sun, 25 Jul 2010 10:07:27 +0000 (UTC) (envelope-from avg@freebsd.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 86A978FC21 for ; Sun, 25 Jul 2010 10:07:26 +0000 (UTC) Received: from porto.topspin.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id NAA03028; Sun, 25 Jul 2010 13:07:24 +0300 (EEST) (envelope-from avg@freebsd.org) Received: from localhost.topspin.kiev.ua ([127.0.0.1]) by porto.topspin.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1Ocy79-000CxD-Ou; Sun, 25 Jul 2010 13:07:23 +0300 Message-ID: <4C4C0CD9.6000002@freebsd.org> Date: Sun, 25 Jul 2010 13:07:21 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: RW References: <4C4B4BAB.3000005@freebsd.org> <20100725003144.3cfead39@gumby.homeunix.com> In-Reply-To: <20100725003144.3cfead39@gumby.homeunix.com> X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: pageout question X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 25 Jul 2010 10:07:27 -0000 on 25/07/2010 02:31 RW said the following: > On Sat, 24 Jul 2010 23:23:07 +0300 > Andriy Gapon wrote: > >> There is a good deal of comments in the vm_pageout.c code that imply >> that we use a hysteresis approach to deal with low available pages >> condition. >> >> >> In general, the hysteresis, the comments and the code make sense. >> My doubt, though, is about the block of code that is right below the >> comment quoted above: >> if (vm_pages_needed && !vm_page_count_min()) { >> if (!vm_paging_needed()) >> vm_pages_needed = 0; >> wakeup(&cnt.v_free_count); >> } > > As I understand it the hysteresis is done inside vm_pageout_scan, and > the expectation is that one pass will typically satisfy this because the > design aims to keep enough clean pages in the inactive queue. I have seen these lines in vm_pageout_scan: /* * Calculate the number of pages we want to either free or move * to the cache. */ page_shortage = vm_paging_target() + addl_page_shortage_init; ... /* * Compute the number of pages we want to try to move from the * active queue to the inactive queue. */ page_shortage = vm_paging_target() + cnt.v_inactive_target - cnt.v_inactive_count; page_shortage += addl_page_shortage; But I am not sure about "clean pages in the inactive queue" part. >From what I can see in the code, pagedaemon only tries to maintain a certain number of pages on inactive queue - I am speaking about vm_pageout_page_stats(). But I do not see any code ensuring level of _clean_ inactive pages. And, if I am not mistaken, there is no guarantee even that those pages will not be re-activated when pagedaemon actually scans them. > I'm not sure if the vm_paging_needed() call is correct or not, but it > may be that that the intent is to avoid immediately going back to a > depleted inactive queue when cache+free is within normal bounds, > because it could result in avoidable paging to swap. Well, OTOH, if the current pass results in many pages being re-activated and many pages still left on the inactive queue because they are dirty (see maxlaunder in vm_pageout_scan), then it is premature to quit paging when we only reached bare minimum of available pages (see pass and maxlaunder again). IMHO, of course. As a side discussion, I wonder if current setting of v_inactive_target is adequate. It "feels" that it should be bigger. -- Andriy Gapon