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