Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 20 May 2012 12:34:26 -0500
From:      Alan Cox <alc@rice.edu>
To:        Marko Zec <zec@fer.hr>
Cc:        alc@freebsd.org, freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org
Subject:   Re: superpages and kmem on amd64
Message-ID:  <4FB92B22.5020304@rice.edu>
In-Reply-To: <201205201643.01194.zec@fer.hr>
References:  <201205200901.32613.zec@fer.hr> <CAJUyCcOWRKw5=NH_WrkKVcOMqGy2f3HroBX=pGbcbS3UbUZkxg@mail.gmail.com> <201205201643.01194.zec@fer.hr>

next in thread | previous in thread | raw e-mail | index | archive | help
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<zec@fer.hr>  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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4FB92B22.5020304>