From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail191.messagelabs.com (mail191.messagelabs.com [216.82.242.19]) by kanga.kvack.org (Postfix) with SMTP id 3BCBA6B01EE for ; Mon, 12 Apr 2010 04:19:10 -0400 (EDT) Date: Mon, 12 Apr 2010 10:18:13 +0200 From: Andrea Arcangeli Subject: Re: [PATCH 00 of 41] Transparent Hugepage Support #17 Message-ID: <20100412081813.GH5656@random.random> References: <4BC0CFF4.5000207@redhat.com> <20100410194751.GA23751@elte.hu> <4BC0DE84.3090305@redhat.com> <20100411104608.GA12828@elte.hu> <4BC1B2CA.8050208@redhat.com> <20100411120800.GC10952@elte.hu> <20100412060931.GP5683@laptop> <20100412070811.GD5656@random.random> <20100412072144.GS5683@laptop> <4BC2D0C9.3060201@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BC2D0C9.3060201@redhat.com> Sender: owner-linux-mm@kvack.org To: Avi Kivity Cc: Nick Piggin , Ingo Molnar , Mike Galbraith , Jason Garrett-Glaser , Linus Torvalds , Pekka Enberg , Andrew Morton , linux-mm@kvack.org, Marcelo Tosatti , Adam Litke , Izik Eidus , Hugh Dickins , Rik van Riel , Mel Gorman , Dave Hansen , Benjamin Herrenschmidt , Mike Travis , KAMEZAWA Hiroyuki , Christoph Lameter , Chris Wright , bpicco@redhat.com, KOSAKI Motohiro , Balbir Singh , Arnd Bergmann , "Michael S. Tsirkin" , Peter Zijlstra , Johannes Weiner , Daisuke Nishimura List-ID: On Mon, Apr 12, 2010 at 10:50:33AM +0300, Avi Kivity wrote: > The problem with hugetlbfs is that you need to commit upfront to using > it, and that you need to be the admin. For virtualization, you want to > use hugepages when there is no memory pressure, but you want to use ksm, > ballooning, and swapping when there is (and then go back to large pages > when pressure is relieved, e.g. by live migration). > > HPC and databases can probably live with hugetlbfs. JVM is somewhere in > the middle, they do allocate memory dynamically. I guess lots of the recent work on hugetlbfs has been exactly meant to try to make hugetlbfs more palatable by things like JVM, the end result is that it's growing in its own parallel VM but very still crippled down compared to the real kernel VM. I see very long term value in hugetlbfs, for example for CPUs that can't mix different page sizes in the same VMA, or for the 1G page reservation (no way we're going to slowdown everything increasing MAX_ORDER so much by default even if fragmentation issues wouldn't grow exponentially with the order) but I think hugetlbfs should remain simple and cover optimally these use cases, without trying to expand itself into the dynamic area of transparent usages where it wasn't designed to be used in the first place and where it's not a too good fit. -- 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