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

[Andrea Arcangeli]

On Fri, Mar 12, 2010 at 06:17:05PM +0000, Paul Brook wrote:
> > > 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
> 
> It's only hypothetical on x86. Many other architectures already support this 
> (at least ARM, MIPS, IA64, SPARC).

Hmm the kernel won't support mixed page size right now but ok this is
irrelevant because the API should stand. I think we'll be lucky enough
if 1 HPAGE size will be supported...

ia64 won't be able to take advantage of it either because it can't mix
different page sizes in the same vma, which is a requirement for
transparency and fallback to regular page size.

My point is that there is no need to show the smaller page sizes to
userland, only the max one is relevant and this isn't going to change
and I'm uncomfortable to add plural stuff to a patch that doesn't
contemplate mixes page sizes and for the time being multiple hpage size
isn't even on the horizon... I hate APIs...

What if we defer this whole issue and we just align on 2M if
/sys/kernel/mm/transparent_hugepage exists without checking /sys? ;)
If there's a way to define the host hpage size that will be enough, 2M
is there since PAE was introduced and it's not going to change
overnight so there's plenty of time later to add a hpage_sizes..