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.
