On Wed, 31 Mar 2010, Andrea Arcangeli wrote: > > 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). Large pages would be more independent from the page table structure with the approach that I outlined earlier since you would not have to do these sync tricks. > 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. There are applications that have benefited for years already from 1G page sizes (available on IA64 f.e.). So why wait? -- 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>