From owner-freebsd-hackers@FreeBSD.ORG Sun May 20 17:42:26 2012 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id EF53C1065674; Sun, 20 May 2012 17:42:26 +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 B33CE8FC17; Sun, 20 May 2012 17:42:26 +0000 (UTC) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id CAFBE290FF2; Sun, 20 May 2012 12:34:27 -0500 (CDT) Received: from mh5.mail.rice.edu (localhost.localdomain [127.0.0.1]) by mh5.mail.rice.edu (Postfix) with ESMTP id BD24B290FE3; Sun, 20 May 2012 12:34:27 -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 Xl56zmO57n7D; Sun, 20 May 2012 12:34:27 -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 37F3E290FD2; Sun, 20 May 2012 12:34:27 -0500 (CDT) Message-ID: <4FB92B22.5020304@rice.edu> Date: Sun, 20 May 2012 12:34:26 -0500 From: Alan Cox User-Agent: Mozilla/5.0 (X11; FreeBSD i386; rv:8.0) Gecko/20111113 Thunderbird/8.0 MIME-Version: 1.0 To: Marko Zec References: <201205200901.32613.zec@fer.hr> <201205201643.01194.zec@fer.hr> In-Reply-To: <201205201643.01194.zec@fer.hr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: alc@freebsd.org, freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org Subject: Re: superpages and kmem on amd64 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: Sun, 20 May 2012 17:42:27 -0000 On 05/20/2012 09:43, Marko Zec wrote: > 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? The count is cumulative. There is no instantaneous count. Subtracting demotions from promotions plus mappings is not a reliable way to get the instantaneous total because a superpage mapping can be destroyed without first being demoted. > 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? Try using pmap_mincore() to verify that the mappings are superpages. > 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)? I suspect that you need to increase the size of your kmem map. Alan