From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 28 05:38:07 2011 Return-Path: Delivered-To: hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2B963106564A; Fri, 28 Oct 2011 05:38:07 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh1.mail.rice.edu (mh1.mail.rice.edu [128.42.201.20]) by mx1.freebsd.org (Postfix) with ESMTP id E2E2D8FC08; Fri, 28 Oct 2011 05:38:06 +0000 (UTC) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id 083BE2916F7; Fri, 28 Oct 2011 00:38:06 -0500 (CDT) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id E5D17297603; Fri, 28 Oct 2011 00:38:05 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh1.mail.rice.edu, auth channel Received: from mh1.mail.rice.edu ([127.0.0.1]) by mh1.mail.rice.edu (mh1.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id RzI8rQSDDtMy; Fri, 28 Oct 2011 00:38:05 -0500 (CDT) Received: from adsl-216-63-78-18.dsl.hstntx.swbell.net (adsl-216-63-78-18.dsl.hstntx.swbell.net [216.63.78.18]) (using TLSv1 with cipher RC4-MD5 (128/128 bits)) (No client certificate requested) (Authenticated sender: alc) by mh1.mail.rice.edu (Postfix) with ESMTPSA id 307F82916F7; Fri, 28 Oct 2011 00:38:05 -0500 (CDT) Message-ID: <4EAA3FBC.3090907@rice.edu> Date: Fri, 28 Oct 2011 00:38:04 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.17) Gecko/20110620 Thunderbird/3.1.10 MIME-Version: 1.0 To: Svatopluk Kraus References: <20111006160159.GQ1511@deviant.kiev.zoral.com.ua> <4E8FF4B8.7010300@rice.edu> <4EA747B5.9040304@rice.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Fri, 28 Oct 2011 11:17:04 +0000 Cc: alc@freebsd.org, Wojciech Puchar , Kostik Belousov , hackers@freebsd.org, Grzegorz Kulewski Subject: Re: mmap performance and memory use 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: Fri, 28 Oct 2011 05:38:07 -0000 On 10/26/2011 06:23, Svatopluk Kraus wrote: > Hi, > > well, I'm working on new port (arm11 mpcore) and pmap_enter_object() > is what I'm debugging rigth now. And I did not find any way in > userland how to force kernel to call pmap_enter_object() which makes > SUPERPAGE mapping without promotion. I tried to call mmap() with > MAP_PREFAULT_READ without success. I tried to call madvise() with > MADV_WILLNEED without success too. > mmap() should call pmap_enter_object() if MAP_PREFAULT_READ was specified. I'm surprised to hear that it's not happening for you. > To make SUPERPAGE mapping, it's obvious that all physical pages under > SUPERPAGE must be allocated in vm_object. And SUPERPAGE mapping must > be done before first access to them, otherwise a promotion is on the > way. MAP_PREFAULT_READ does nothing with it. If madvice() is used, > vm_object_madvise() is called but only cached pages are allocated in > advance. Of coarse, an allocation of all physical memory behind > virtual address space in advance is not preferred in most situations. > > For example, I want to do some computation on 4M memory space (I know > that each byte will be accessed) and want to utilize SUPERPAGE mapping > without promotion, so save 4K page table (i386 machine). However, > malloc() leads to promotion, mmap() with MAP_PREFAULT_READ doesn't do > nothing so SUPERPAGE mapping is promoted, and madvice() with > MADV_WILLNEED calls vm_object_madvise() but because the pages are not > cached (how can be on anonymous memory), it is not work without > promotion too. > > So, SUPERPAGE mapping without promotions is fine, but it can be done > only if physical memory being mapped is already allocated. Is it > really possible to force that in userland? > To force the allocation of the physical memory? Right now, the only way is for your program to touch the pages. > Moreover, the SUPERPAGE mapping is made readonly firstly. So, even if > I have SUPERPAGE mapping without promotion, the mapping is demoted > after first write, and promoted again after all underlying pages are > accessed by write. There is 4K page table saving no longer. > Yes, that is all true. It is possible to change things so that the page table pages are reclaimed after a time, and not kept around indefinitely. However, this not high on my personal priority list. Before that, it is more likely that I will add an option to avoid the demotion on write, if we don't have to copy the entire superpage to do so. Alan