From owner-freebsd-hackers@FreeBSD.ORG Thu Apr 5 19:33:51 2012 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 2017D106566B for ; Thu, 5 Apr 2012 19:33:51 +0000 (UTC) (envelope-from andrey@zonov.org) Received: from mail-bk0-f54.google.com (mail-bk0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 91FB48FC12 for ; Thu, 5 Apr 2012 19:33:50 +0000 (UTC) Received: by bkcjc3 with SMTP id jc3so2016738bkc.13 for ; Thu, 05 Apr 2012 12:33:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=dCDYOvcYYl6FVmZwZAQ/b/9O/6HAqokN4FlSFvB2UqA=; b=hwOK6FS2k0/JKJdo8UKPK1g4oPMV+ln/Z1EDGEuI4FgGUoNUOEadsSu3mM4tmfRauw dUUXuJUK8jYewrLO0z6QyuJO/eKJHfMz6G2g8nHUu3Z8KpW1+Tg7qdxfPvCHbLtTEOja /kuGnB/bJ3wl/NCY5NqSYo+a7IhbqAUXmTPwsbseXe8upRSBZ8bSC0ReYwP8g5yADfi1 +R2AW1bheA8uQsOZbD0bOVJ1SvW4eSPRJREhaGHte53DT7LRueXO4wXZvFoMsMs6Pxrq M2NkRkKQ+cpnxq7DXegYjf/n54Mdz5ruTH6r247OvVdN5+rhJ8ITxryaQFgyr7RIFpl2 48Fw== Received: by 10.204.148.80 with SMTP id o16mr1868400bkv.3.1333654429247; Thu, 05 Apr 2012 12:33:49 -0700 (PDT) Received: from [10.254.254.77] (ppp95-165-133-149.pppoe.spdop.ru. [95.165.133.149]) by mx.google.com with ESMTPS id f5sm10539041bke.9.2012.04.05.12.33.48 (version=SSLv3 cipher=OTHER); Thu, 05 Apr 2012 12:33:48 -0700 (PDT) Message-ID: <4F7DF39A.3000500@zonov.org> Date: Thu, 05 Apr 2012 23:33:46 +0400 From: Andrey Zonov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; ru; rv:1.8.1.24) Gecko/20100228 Thunderbird/2.0.0.24 Mnenhy/0.7.6.0 MIME-Version: 1.0 To: Alan Cox References: <4F7B495D.3010402@zonov.org> <20120404071746.GJ2358@deviant.kiev.zoral.com.ua> <4F7DC037.9060803@rice.edu> In-Reply-To: <4F7DC037.9060803@rice.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQktlePz3WbQ65VBhrYLSxdJu5lCfUyoiJdeaW+ZDGBUaIGuIZUpgplsUVWCIpAa1Ws0LT/f Cc: Konstantin Belousov , freebsd-hackers@freebsd.org, alc@freebsd.org Subject: Re: problems with mmap() and disk caching 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: Thu, 05 Apr 2012 19:33:51 -0000 On 05.04.2012 19:54, Alan Cox wrote: > On 04/04/2012 02:17, Konstantin Belousov wrote: >> On Tue, Apr 03, 2012 at 11:02:53PM +0400, Andrey Zonov wrote: [snip] >>> This is what I expect. But why this doesn't work without reading file >>> manually? >> Issue seems to be in some change of the behaviour of the reserv or >> phys allocator. I Cc:ed Alan. > > I'm pretty sure that the behavior here hasn't significantly changed in > about twelve years. Otherwise, I agree with your analysis. > > On more than one occasion, I've been tempted to change: > > pmap_remove_all(mt); > if (mt->dirty != 0) > vm_page_deactivate(mt); > else > vm_page_cache(mt); > > to: > > vm_page_dontneed(mt); > Thanks Alan! Now it works as I expect! But I have more questions to you and kib@. They are in my test below. So, prepare file as earlier, and take information about memory usage from top(1). After preparation, but before test: Mem: 80M Active, 55M Inact, 721M Wired, 215M Buf, 46G Free First run: $ ./mmap /mnt/random mmap: 1 pass took: 7.462865 (none: 0; res: 262144; super: 0; other: 0) No super pages after first run, why?.. Mem: 79M Active, 1079M Inact, 722M Wired, 216M Buf, 45G Free Now the file is in inactive memory, that's good. Second run: $ ./mmap /mnt/random mmap: 1 pass took: 0.004191 (none: 0; res: 262144; super: 511; other: 0) All super pages are here, nice. Mem: 1103M Active, 55M Inact, 722M Wired, 216M Buf, 45G Free Wow, all inactive pages moved to active and sit there even after process was terminated, that's not good, what do you think? Read the file: $ cat /mnt/random > /dev/null Mem: 79M Active, 55M Inact, 1746M Wired, 1240M Buf, 45G Free Now the file is in wired memory. I do not understand why so. Could you please give me explanation about active/inactive/wired memory? > because I suspect that the current code does more harm than good. In > theory, it saves activations of the page daemon. However, more often > than not, I suspect that we are spending more on page reactivations than > we are saving on page daemon activations. The sequential access > detection heuristic is just too easily triggered. For example, I've seen > it triggered by demand paging of the gcc text segment. Also, I think > that pmap_remove_all() and especially vm_page_cache() are too severe for > a detection heuristic that is so easily triggered. > [snip] -- Andrey Zonov