From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail143.messagelabs.com (mail143.messagelabs.com [216.82.254.35]) by kanga.kvack.org (Postfix) with SMTP id EC9E06B01EF for ; Mon, 12 Apr 2010 06:25:01 -0400 (EDT) Date: Mon, 12 Apr 2010 12:23:53 +0200 From: Andrea Arcangeli Subject: Re: [PATCH 00 of 41] Transparent Hugepage Support #17 Message-ID: <20100412102353.GV5656@random.random> References: <20100412060931.GP5683@laptop> <4BC2BF67.80903@redhat.com> <20100412071525.GR5683@laptop> <4BC2CF8C.5090108@redhat.com> <20100412082844.GU5683@laptop> <4BC2E1D6.9040702@redhat.com> <20100412092615.GY5683@laptop> <4BC2EFBA.5080404@redhat.com> <20100412100806.GU5656@random.random> <4BC2F1A6.3070202@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BC2F1A6.3070202@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 01:10:46PM +0300, Avi Kivity wrote: > On 04/12/2010 01:08 PM, Andrea Arcangeli wrote: > > On Mon, Apr 12, 2010 at 01:02:34PM +0300, Avi Kivity wrote: > > > >> The only scenario I can see where it degrades is that you have a dcache > >> load that spills over to all of memory, then falls back leaving a pinned > >> page in every huge frame. It can happen, but I don't see it as a likely > >> scenario. But maybe I'm missing something. > >> > > And in my understanding this is exactly the scenario that kernelcore= > > should prevent from ever materialize. Providing math guarantees > > without kernelcore= is probably futile. > > > > Well, that forces the user to make a different boot-time tradeoff. It's > unsatisfying. Well this is just about the math guarantee, like disabling memory overcommit to have better guarantee not to run into the oom killer... most people won't need this but it can address the math concerns. I think it's enough if people wants a guarantee and it won't require using nonlinear mapping for kernel. -- 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