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<z...@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
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
