> 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
