Re: [PATCH 00 of 34] Transparent Hugepage support #14

[Johannes Weiner <hannes@cmpxchg.org>]

On Mon, Mar 22, 2010 at 10:38:23AM -0500, Christoph Lameter wrote:
> On Fri, 19 Mar 2010, Andrea Arcangeli wrote:
> > defrag, migration they all can fail, split_huge_page cannot. The very
> > simple reason split_huge_page cannot fail is this: if I have to do
> > anything more than a one liner to make mremap, mprotect and all the
> > rest, then I prefer to take your non-practical more risky design. The
> > moment you have to alter some very inner pagetable walking function to
> > handle a split_huge_page error return, you'll already have to recraft
> > the code in a big enough way, that you better make it hugepage
> > aware. Making it hugepage aware is like 10 times more difficult and
> > error prone and hard to test, than handling a split_huge_page error
> > retval, but still in 10 files fixed for the error retval, will be
> > worth 1 file converted not to call split_huge_page at all. That
> > explains very clearly my decision to make split_huge_page not fail,
> > and make sure all next efforts will be spent in removing
> > split_huge_page and not in handling an error retval for a function
> > that shouldn't have been called in the first place!
> 
> We already have 2M pmd handling in the kernel and can consider huge pmd
> entries while walking the page tables! Go incrementally use what
> is there.

That only works if you merely read the tables.  If the VMA gets broken
up in the middle of a huge page, you definitely have to map ptes again.

And as already said, allowing it to happen always-succeeding and
atomically allows to switch users step by step.

That sure sounds more incremental to me than being required to do
non-trivial adjustments to all the places at once!

--
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>