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

[Andrea Arcangeli <aarcange@redhat.com>]

On Fri, Mar 12, 2010 at 05:10:54PM +0000, Paul Brook wrote:
> > > So shouldn't [the name of] the value the kernel provides for recommended
> > > alignment be equally implementation agnostic?
> > 
> > Is sys/kernel/mm/transparent_hugepage directory implementation
> > agnostic in the first place?
> 
> It's about as agnostic as MADV_HUGEPAGE :-)

Exactly! ;) Again it's no black and white... we expose a minimum so
the kernel later can do better for qemu.

> > If we want to fully take advantage of the feature (i.e. NPT and qemu
> > first 2M of guest physical ram where usually kernel resides) userspace
> > has to know the alignment size the kernel recommends.
> 
> This is KVM specific, so my gut reaction is you should be asking KVM.

Hey I just said this is also needed for qemu to be backed by hugepages
on the first 2M of guest ram. Not KVM specific anymore if we want to
optimize that bit too. Performance difference for small system with
one qemu only, will be in the 2% range, for KVM it's from 6% to 15%
depending on the workload. But it's not kvm specific.

> No particular preference. Or you could have .../page_sizes list all available 
> sizes, and have qemu take the first one (or last depending on sort order).

That would also work. Considering that the current transparent
hugepage support won't support any more than 1 page, I think it's ok
to call it hpage_size, the fact that amd/intel will add a 64k page
size is purely hypothetical and I guess by the time transparent
hugepages are 1G in size, the basic page will be 2M and 4k will be
obsolete. But hey if you prefer page_sizes or max_page_size let me
know... The semantics will be able to stand for the long run, I'll
write hpage_size shall export the alignment that userland should use
with posix_memalign to be sure the whole allocated space can be backed
by hugepages.