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

[Andrea Arcangeli]

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.

What we could ask the kernel is the HPAGE_SIZE. Also thinking a bit
more about it, it now comes to mind what we really care about is the
HOST_HPAGE_SIZE. Said that I doubt for kvm it makes a lot of
difference and this only changes the kvm path. I'm open to suggestions
of where to get the HPAGE_SIZE from and how to call it...

> Failing that, modify qemu_memalign() to trim excess memory.
> 
> Come to think of it, posix_memalign() needs to do that (but doesn't).

It's hard to tell because of the amount of #ifdefs in .c files, but it
seems to be using posix_memalign.

If we don't touch these additional pages allocated and there's no
transparent hugepage support in the kernel, you won't waste any more
memory and less vmas will be generated this way than with a kernel
option to reduce the virtual memory waste. Basically the idea is to
waste virtual memory to avoid wasting cpu.

In short we should make sure it only wastes virtual memory...