> On Fri, Mar 12, 2010 at 04:04:03PM +0000, Paul Brook wrote: > > > > > $ cat /sys/kernel/mm/transparent_hugepage/hpage_pmd_size > > > > > 2097152 > > > Hmm, ok. I'm guessing linux doesn't support anything other than "huge" > > and "normal" page sizes now, so it's a question of whether we want it to > > expose current implementation details, or say "Align big in-memory things > > this much for optimal TLB behavior". > > hugetlbfs already exposes the implementation detail. So if you want > that it's already available. The whole point of going the extra mile > with a transparent solution is to avoid userland to increase in > complexity and to keep it as unaware of hugepages as possible. The > madvise hint basically means "this won't risk to waste memory if you > use large tlb on this mapping" and also "this mapping is more > important than others to be backed by hugepages". It's up to the > kernel what to do next. For example right now khugepaged doesn't > prioritize scanning the madvise regions first, it basically doesn't > matter for hypervisor solutions in the cloud (all anon memory in the > system is only allocated by kvm...). But later we may prioritize it > and try to be smarter from the hint given by userland.
So shouldn't [the name of] the value the kernel provides for recommended alignment be equally implementation agnostic? Paul
