From owner-freebsd-hackers@FreeBSD.ORG Fri Oct 7 17:23:55 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 A78BE106564A for ; Fri, 7 Oct 2011 17:23:55 +0000 (UTC) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from wojtek.tensor.gdynia.pl (wojtek.tensor.gdynia.pl [89.206.35.99]) by mx1.freebsd.org (Postfix) with ESMTP id E2CBC8FC13 for ; Fri, 7 Oct 2011 17:23:54 +0000 (UTC) Received: from wojtek.tensor.gdynia.pl (localhost [127.0.0.1]) by wojtek.tensor.gdynia.pl (8.14.5/8.14.4) with ESMTP id p97HNoJ1008788; Fri, 7 Oct 2011 19:23:50 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Received: from localhost (wojtek@localhost) by wojtek.tensor.gdynia.pl (8.14.5/8.14.4/Submit) with ESMTP id p97HNoTg008785; Fri, 7 Oct 2011 19:23:50 +0200 (CEST) (envelope-from wojtek@wojtek.tensor.gdynia.pl) Date: Fri, 7 Oct 2011 19:23:50 +0200 (CEST) From: Wojciech Puchar To: alc@freebsd.org In-Reply-To: Message-ID: References: <20111006160159.GQ1511@deviant.kiev.zoral.com.ua> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="1626729238-606807853-1318008230=:8664" X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.2.7 (wojtek.tensor.gdynia.pl [127.0.0.1]); Fri, 07 Oct 2011 19:23:50 +0200 (CEST) Cc: 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, 07 Oct 2011 17:23:55 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --1626729238-606807853-1318008230=:8664 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8BIT > > 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? 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. --1626729238-606807853-1318008230=:8664--