From owner-freebsd-hackers@FreeBSD.ORG Sat Jul 24 20:23:10 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 57F49106564A for ; Sat, 24 Jul 2010 20:23:10 +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 D64498FC14 for ; Sat, 24 Jul 2010 20:23:09 +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 XAA26368 for ; Sat, 24 Jul 2010 23:23:08 +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 1OclFT-000A3g-Rn for freebsd-hackers@FreeBSD.org; Sat, 24 Jul 2010 23:23:07 +0300 Message-ID: <4C4B4BAB.3000005@freebsd.org> Date: Sat, 24 Jul 2010 23:23:07 +0300 From: Andriy Gapon User-Agent: Thunderbird 2.0.0.24 (X11/20100603) MIME-Version: 1.0 To: freebsd-hackers@freebsd.org X-Enigmail-Version: 0.96.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: 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: Sat, 24 Jul 2010 20:23:10 -0000 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. Evidence 1: /* * v_free_target and v_cache_min control pageout hysteresis. Note * that these are more a measure of the VM cache queue hysteresis * then the VM free queue. Specifically, v_free_target is the * high water mark (free+cache pages). * * v_free_reserved + v_cache_min (mostly means v_cache_min) is the * low water mark, while v_free_min is the stop. [...] Evidence 2: /* * [...] Do * not clear vm_pages_needed until we reach our target, * otherwise we may be woken up over and over again and * waste a lot of cpu. */ 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); } If I read this code correctly, pagedaemon would go idle as soon as vm_paging_needed() becomes false. Given the defintion of vm_paging_needed as (v_free_reserved + v_cache_min) > (v_free_count + v_cache_count) this means that pagedaemon quits paging as soon as available page count is above _low_ watermark. Which contradicts the comments and the general logic of the code. (Paging also generally starts only when vm_paging_needed() is true). I think that it also means that vm_pageout_scan is called with pass > 0 only in very very low memory conditions, where the first pass (pass=0) wasn't able to free up memory even above low watermark. But my impression is that the intention was to keep pagedaemon working until high watermark was reached (vm_paging_target() < 0). Plus, perhaps, some more depending on vm_pageout_deficit. And, yes, I see that vm_pageout_scan() has a goal of reaching vm_paging_target() + vm_pageout_deficit, but I am speaking of the case where it is unable to do so on the first pass. Do I misunderstand something? Is there a flaw in the code or are the comments outdated/misleading/not-descriptive-enough? -- Andriy Gapon