Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 20 May 2012 16:43:00 +0200
From:      Marko Zec <zec@fer.hr>
To:        <alc@freebsd.org>
Cc:        freebsd-hackers@freebsd.org, freebsd-amd64@freebsd.org
Subject:   Re: superpages and kmem on amd64
Message-ID:  <201205201643.01194.zec@fer.hr>
In-Reply-To: <CAJUyCcOWRKw5=NH_WrkKVcOMqGy2f3HroBX=pGbcbS3UbUZkxg@mail.gmail.com>
References:  <201205200901.32613.zec@fer.hr> <CAJUyCcOWRKw5=NH_WrkKVcOMqGy2f3HroBX=pGbcbS3UbUZkxg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
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?

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



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