From owner-freebsd-hackers@FreeBSD.ORG Tue Oct 11 16:12:46 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 B594A1065677; Tue, 11 Oct 2011 16:12:46 +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 736448FC0A; Tue, 11 Oct 2011 16:12:46 +0000 (UTC) Received: from mh1.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh1.mail.rice.edu (Postfix) with ESMTP id C430229192C; Tue, 11 Oct 2011 11:12:45 -0500 (CDT) X-SMTP-Auth: no X-SMTP-Auth: no X-SMTP-Auth: no X-SMTP-Auth: no X-SMTP-Auth: no Received: from proofpoint2.rice.edu (proofpoint2.rice.edu [128.42.182.232]) by mh1.mail.rice.edu (Postfix) with ESMTP id A571A291914; Tue, 11 Oct 2011 11:12:45 -0500 (CDT) Received: from mh7.mail.rice.edu (mh7.mail.rice.edu [128.42.199.46]) by proofpoint2.rice.edu (8.14.4/8.14.4) with ESMTP id p9BGCjXT010025; Tue, 11 Oct 2011 11:12:45 -0500 Received: from mh7.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh7.mail.rice.edu (Postfix) with ESMTP id 323CA291CCE; Tue, 11 Oct 2011 11:12:45 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh7.mail.rice.edu, auth channel Received: from mh7.mail.rice.edu ([127.0.0.1]) by mh7.mail.rice.edu (mh7.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id VhZKcaG9RUg0; Tue, 11 Oct 2011 11:12:44 -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 mh7.mail.rice.edu (Postfix) with ESMTPSA id 58EBE291D11; Tue, 11 Oct 2011 11:12:44 -0500 (CDT) Message-ID: <4E946AFA.6060105@rice.edu> Date: Tue, 11 Oct 2011 11:12:42 -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: Wojciech Puchar References: <20111006160159.GQ1511@deviant.kiev.zoral.com.ua> <4E8FF4B8.7010300@rice.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 11 Oct 2011 16:43:36 +0000 Cc: alc@freebsd.org, 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: Tue, 11 Oct 2011 16:12:46 -0000 On 10/10/2011 16:28, Wojciech Puchar wrote: >> >> Notice that vm.pmap.pde.promotions increased by 31. This means that >> 31 superpage mappings were created by promotion from small page >> mappings. > > thank you. i looked at .mappings as it seemed logical for me that is > shows total. > >> In contrast, vm.pmap.pde.mappings counts superpage mappings that are >> created directly and not by promotion from small page mappings. For >> example, if a large executable, such as gcc, is resident in memory, >> the text segment will be pre-mapped using superpage mappings, >> avoiding soft fault and promotion overhead. Similarly, mmap(..., >> MAP_PREFAULT_READ) on a large, memory resident file may pre-map the >> file using superpage mappings. > > your options are not described in mmap manpage nor madvise > (MAP_PREFAULT_READ). > > when can i find the up to date manpage or description? > It is documented in mmap(2) on HEAD and 9.x: MAP_PREFAULT_READ Immediately update the calling process's lowest-level virtual address translation structures, such as its page table, so that every memory resident page within the region is mapped for read access. Ordinarily these structures are updated lazily. The effect of this option is to eliminate any soft faults that would oth- erwise occur on the initial read accesses to the region. Although this option does not preclude prot from including PROT_WRITE, it does not eliminate soft faults on the initial write accesses to the region. I don't believe that this feature was merged into to 8.x. However, there is no technical reason that it can't be merged. > > is it possible to force VM subsystem to operate on superpages when > possible - i mean swapping in 2MB chunks? > Currently, no. For some applications, like the Sun/Oracle JVM, that have code to explicitly manage large pages, there could be some benefit in the form of reduced overhead. So, it's on my "to do" list, but no where near the top of that list. Alan