From owner-freebsd-amd64@FreeBSD.ORG Sun May 20 14:45:03 2012 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 871221065670; Sun, 20 May 2012 14:45:03 +0000 (UTC) (envelope-from zec@fer.hr) Received: from mail.zvne.fer.hr (slavko2.zvne.fer.hr [161.53.66.5]) by mx1.freebsd.org (Postfix) with ESMTP id 102AE8FC08; Sun, 20 May 2012 14:45:02 +0000 (UTC) Received: from munja.zvne.fer.hr (161.53.66.248) by mail.zvne.fer.hr (161.53.66.5) with Microsoft SMTP Server id 14.2.298.4; Sun, 20 May 2012 16:45:00 +0200 Received: from sluga.fer.hr ([161.53.66.244]) by munja.zvne.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 May 2012 16:45:00 +0200 Received: from localhost ([161.53.19.8]) by sluga.fer.hr with Microsoft SMTPSVC(6.0.3790.4675); Sun, 20 May 2012 16:43:06 +0200 From: Marko Zec To: Date: Sun, 20 May 2012 16:43:00 +0200 User-Agent: KMail/1.9.10 References: <201205200901.32613.zec@fer.hr> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-ID: <201205201643.01194.zec@fer.hr> X-OriginalArrivalTime: 20 May 2012 14:43:06.0377 (UTC) FILETIME=[DE27FF90:01CD3696] Cc: freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: superpages and kmem on amd64 X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 20 May 2012 14:45:03 -0000 On Sunday 20 May 2012 09:25:59 Alan Cox wrote: > On Sun, May 20, 2012 at 2:01 AM, Marko Zec wrote: > > Hi all, > > > > I'm playing with an algorithm which makes use of large contiguous blocks > > of kernel memory (ranging from 1M to 1G in size), so it would be nice if > > those could be somehow forcibly mapped to superpages. I was hoping that > > the VM system would automagically map (merge) contiguous 4k pages to > > superpages, but > > apparently it doesn't: > > > > vm.pmap.pdpe.demotions: 2 > > vm.pmap.pde.promotions: 543 > > vm.pmap.pde.p_failures: 266253 > > vm.pmap.pde.mappings: 0 > > vm.pmap.pde.demotions: 31 > > No, your conclusion is incorrect. These counts show that 543 superpage > mappings were created by promotion. OK, that sounds promising. Does "created by promotion" count reflect historic / cumulative stats, or is vm.pmap.pde.promotions the actual number of superpages active? Or should we subtract vm.pmap.pde.demotions from it to get the current value? In any case, I wish to be certain that a particular kmem virtual address range is mapped to superpages - how can I enforce that at malloc time, and / or find out later if I really got my kmem mapped to superpages? Perhaps vm_map_lookup() could provide more info, but I'm wondering if someone already wrote a wrapper function for that, which takes only the base virtual address as a single argument? BTW, apparently malloc(size, M_TEMP, M_NOWAIT) requests fail for size > 1G, even at boot time. Any ideas how to circumvent that (8.3-STABLE, amd64, 4G physical RAM)? Thanks, Marko