Re: [Qemu-devel] [PATCH QEMU] transparent hugepage support

[Andrea Arcangeli <aarcange@redhat.com>]

On Sat, Mar 13, 2010 at 10:28:32AM +0200, Avi Kivity wrote:
> On 03/11/2010 06:05 PM, Andrea Arcangeli wrote:
> > On Thu, Mar 11, 2010 at 05:52:16PM +0200, Avi Kivity wrote:
> >    
> >> That is a little wasteful.  How about a hint to mmap() requesting proper
> >> alignment (MAP_HPAGE_ALIGN)?
> >>      
> > So you suggest adding a new kernel feature to mmap? Not sure if it's
> > worth it, considering it'd also increase the number of vmas because it
> > will have to leave an hole. Wasting 2M-4k of virtual memory is likely
> > cheaper than having 1 more vma in the rbtree for every page fault. So
> > I think it's better to just malloc and adjust ourselfs on the next
> > offset which is done in userland by qemu_memalign I think.
> >
> >    
> 
> Won't we get a new vma anyway due to the madvise() call later?

As long as MADV_HUGEPAGE is set in all, it will merge the vmas
together.

So if we do stuff like "alloc from 0 to 4G-4k" and then alloc "4G to
8G" this will avoid a vma split. (initially the mmap will create a
vma, but it'll be immediately removed from madvise with vma_merge)

> But I agree it isn't worth it.

2 vma or 1 vma isn't measurable of course, but yes the point is that
it's not worth it because doing it in userland is theoretically better
too for performance.