From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail202.messagelabs.com (mail202.messagelabs.com [216.82.254.227]) by kanga.kvack.org (Postfix) with SMTP id C40C56B01EE for ; Wed, 31 Mar 2010 12:24:57 -0400 (EDT) Date: Wed, 31 Mar 2010 11:24:02 -0500 (CDT) From: Christoph Lameter Subject: Re: [PATCH 00 of 41] Transparent Hugepage Support #16 In-Reply-To: <20100331153339.GK5825@random.random> Message-ID: References: <20100331141035.523c9285.kamezawa.hiroyu@jp.fujitsu.com> <20100331153339.GK5825@random.random> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org To: Andrea Arcangeli Cc: KAMEZAWA Hiroyuki , linux-mm@kvack.org, Andrew Morton , 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 , Chris Wright , bpicco@redhat.com, KOSAKI Motohiro , Balbir Singh , Arnd Bergmann , "Michael S. Tsirkin" , Peter Zijlstra , Johannes Weiner , Daisuke Nishimura List-ID: 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@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org