From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51]) by kanga.kvack.org (Postfix) with ESMTP id A3C0B6B01B1 for ; Mon, 22 Mar 2010 12:35:41 -0400 (EDT) Date: Mon, 22 Mar 2010 17:35:23 +0100 From: Johannes Weiner Subject: Re: [PATCH 00 of 34] Transparent Hugepage support #14 Message-ID: <20100322163523.GA12407@cmpxchg.org> References: <20100318234923.GV29874@random.random> <20100319144101.GB29874@random.random> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org To: Christoph Lameter Cc: Andrea Arcangeli , linux-mm@kvack.org, Marcelo Tosatti , Adam Litke , Avi Kivity , Izik Eidus , Hugh Dickins , Nick Piggin , Rik van Riel , Mel Gorman , Dave Hansen , Benjamin Herrenschmidt , Ingo Molnar , Mike Travis , KAMEZAWA Hiroyuki , Chris Wright , bpicco@redhat.com, KOSAKI Motohiro , Balbir Singh , Arnd Bergmann , "Michael S. Tsirkin" , Peter Zijlstra List-ID: 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: email@kvack.org