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

[Paul Brook <paul@codesourcery.com>]

> On Thu, Mar 11, 2010 at 05:55:10PM +0000, Paul Brook wrote:
> > sysconf(_SC_HUGEPAGESIZE); would seem to be the obvious answer.
> 
> There's not just one hugepage size 

We only have one madvise flag...

> and that thing doesn't exist yet
> plus it'd require mangling over glibc too. If it existed I could use
> it but I think this is better:
 
> $ cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size
> 2097152

Is "pmd" x86 specific?

> > If the allocation size is not a multiple of the preferred alignment, then
> > you probably loose either way, and we shouldn't be requesting increased
> > alignment.
> 
> That's probably good idea. Also note, if we were to allocate
> separately the 0-640k 1m-end, for NPT to work we'd need to start the
> second block misaligned at a 1m address. So maybe I should move the
> alignment out of qemu_ram_alloc and have it in the caller?

I think the only viable solution if you care about EPT/NPT is to not do that. 
With your current code the 1m-end region will be misaligned - your code 
allocates it on a 2M boundary. I suspect you actually want (base % 2M) == 1M. 
Aligning on a 1M boundary will only DTRT half the time.
 
> > I wouldn't be surprised if putting the start of guest ram on a large TLB
> > entry was a win. Your guest kernel often lives there!
> 
> Yep, that's easy to handle with the hpage_pmd_size ;).

But that's only going to happen if you align the allocation.

> > Assuming we're allocating in large chunks, I doubt an extra hugepage
> > worth of VMA is a big issue.
> >
> > Either way I'd argue that this isn't something qemu should have to care
> > about, and is actually a bug in posix_memalign.
> 
> Hmm the last is a weird claim considering posix_memalign gets an explicit
> alignment parameter and it surely can't choose what alignment to
> use. We can argue about the kernel side having to align automatically
> but again if it would do that, it'd generate unnecessary vma holes
> which we don't want.

It can't choose what align to use, but it can (should?) choose how to achieve 
that alignment.

Paul