From owner-freebsd-hackers@FreeBSD.ORG Sat Oct 8 07:16:38 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 6F860106566B for ; Sat, 8 Oct 2011 07:16:38 +0000 (UTC) (envelope-from alc@rice.edu) Received: from mh5.mail.rice.edu (mh5.mail.rice.edu [128.42.199.32]) by mx1.freebsd.org (Postfix) with ESMTP id 2F36A8FC15 for ; Sat, 8 Oct 2011 07:16:37 +0000 (UTC) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id B55502909DA; Sat, 8 Oct 2011 01:59:06 -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 mh5.mail.rice.edu (Postfix) with ESMTP id 926AA290986; Sat, 8 Oct 2011 01:59:06 -0500 (CDT) Received: from mh5.mail.rice.edu (mh5.mail.rice.edu [128.42.199.32]) by proofpoint2.rice.edu (8.14.4/8.14.4) with ESMTP id p986x6SB031704; Sat, 8 Oct 2011 01:59:06 -0500 Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id 58A1C290A05; Sat, 8 Oct 2011 01:59:06 -0500 (CDT) X-Virus-Scanned: by amavis-2.6.4 at mh5.mail.rice.edu, auth channel Received: from mh5.mail.rice.edu ([127.0.0.1]) by mh5.mail.rice.edu (mh5.mail.rice.edu [127.0.0.1]) (amavis, port 10026) with ESMTP id 04uNlTbLtc+X; Sat, 8 Oct 2011 01:59:06 -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 mh5.mail.rice.edu (Postfix) with ESMTPSA id B36292909DA; Sat, 8 Oct 2011 01:59:05 -0500 (CDT) Message-ID: <4E8FF4B8.7010300@rice.edu> Date: Sat, 08 Oct 2011 01:59: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: Wojciech Puchar References: <20111006160159.GQ1511@deviant.kiev.zoral.com.ua> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Mon, 10 Oct 2011 16:24:40 +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: Sat, 08 Oct 2011 07:16:38 -0000 On 10/07/2011 12:23, Wojciech Puchar wrote: >> >> You are correct about the page table page. However, a superpage >> mapping consumes a single PV entry, in place of 512 or 1024 PV >> entries. This winds up saving about three physical pages worth of >> memory for every superpage mapping. > does it actually work? > Yes, the sysctl output shows that it is working. You can also verify this with mincore(2). > simple test > > before (only idle system with 2GB RAM and most free) > > vm.pmap.pde.promotions: 921 > vm.pmap.pde.p_failures: 21398 > vm.pmap.pde.mappings: 299 > vm.pmap.pde.demotions: 596 > vm.pmap.shpgperproc: 200 > vm.pmap.pv_entry_max: 696561 > vm.pmap.pg_ps_enabled: 1 > vm.pmap.pat_works: 1 > > > and with that program running (==sleeping) > > #include > int a[1<<24]; > main() { > int b; > for(b=0;b<(1<<24);b++) a[b]=b; > sleep(1000); > } > > > vm.pmap.pdpe.demotions: 0 > vm.pmap.pde.promotions: 952 > vm.pmap.pde.p_failures: 21398 > vm.pmap.pde.mappings: 299 > vm.pmap.pde.demotions: 596 > vm.pmap.shpgperproc: 200 > vm.pmap.pv_entry_max: 696561 > vm.pmap.pg_ps_enabled: 1 > vm.pmap.pat_works: 1 > > > > seems like i don't understand what these sysctl things mean (i did > sysctl -d) > or it doesn't really work. with program allocating and using linear > 64MB chunk it should be 31 or 32 more mappings in vm.pmap.pde.mappings > there are zero difference. Notice that vm.pmap.pde.promotions increased by 31. This means that 31 superpage mappings were created by promotion from small page mappings. 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. Alan