Re: [PATCH 00 of 41] Transparent Hugepage Support #16

[Andrea Arcangeli <aarcange@redhat.com>]

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@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>