From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail190.messagelabs.com (mail190.messagelabs.com [216.82.249.51]) by kanga.kvack.org (Postfix) with SMTP id E0C326B01EE for ; Mon, 12 Apr 2010 09:18:21 -0400 (EDT) Date: Mon, 12 Apr 2010 15:17:11 +0200 From: Andrea Arcangeli Subject: Re: [PATCH 00 of 41] Transparent Hugepage Support #17 Message-ID: <20100412131711.GX5656@random.random> References: <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> <20100412080626.GG5656@random.random> <20100412104451.GO25756@csn.ul.ie> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100412104451.GO25756@csn.ul.ie> Sender: owner-linux-mm@kvack.org To: Mel Gorman Cc: Nick Piggin , Ingo Molnar , Avi Kivity , 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 , 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 11:44:51AM +0100, Mel Gorman wrote: > As a side-note, this is what dynamic hugepage pool resizing was for. > > hugeadm --pool-pages-max :[+|-]> > > The hugepage pool grows and shrinks as required if the system is able to > allocate the huge pages. If the huge pages are not available, mmap() returns > NULL and userspace is expected to recover by retrying the allocation with > small pages (something libhugetlbfs does automatically). If 99% of the virtual space is backed by hugepages and just the last 2M have to be backed by regular pages that's fine with us, we want to use hugepages for the 99% of the memory. > In the virtualisation context, the greater problem with such an approach > is no-overcommit is possible. I am given to understand that this is a > major problem because hosts of virtual machines are often overcommitted > on the assumption they don't all peak at the same time. Yep, other things that come to mind is that we need KSM to split and merge hugepages when they're found equal, not yet working right now but it's more natural to do it in the core VM as KSM pages then have to be swapped too and mixed in the same vma with regular pages and hugepages. -- 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