On Wed, Mar 31, 2010 at 02:10:35PM +0900, KAMEZAWA Hiroyuki wrote: > Hmm, recently, I noticed that x86-64 has hugepage_size == pmd_size but we can't > assume that in generic. I know your code depends on x86-64 by CONFIG. > Can this implementation be enhanced for various hugepage in generic archs ? > I doubt based-on-pmd approach will get sucess in generic archs.. > > I'm sorry if you answered someone already. The generic archs without pmd approach can't mix hugepages and regular pages in the same vma, so they can't provide graceful fallback and never fail an allocation despite there is pleny of memory free which is one critical fundamental point in the design (and later collapse those with khugepaged which also can run memory compaction asynchronously in the background and not synchronously during page fault which would be entirely worthless for short lived allocations). Until they can mix pages of different size in the same vma they should stick to hugetlbfs anyway so it's futile to worry about those. If there's some that can mix pages of different size in the same vma, and that can't work with this model, I'd be interested to know (not that I plan many changes but still it'd be interesting to evaluate it). About the HPAGE_PMD_ prefix it's not only HPAGE_ like I did initially, in case we later decide to split/collapse 1G pages too but frankly I think by the time memory size doubles 512 times across the board (to make 1G pages a not totally wasted effort to implement in the transparent hugepage support) we'd better move the PAGE_SIZE to 2M and stick to the HPAGE_PMD_ again. -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>