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 8965D6B01F6 for ; Tue, 6 Apr 2010 14:01:58 -0400 (EDT) Date: Tue, 6 Apr 2010 13:00:43 -0500 (CDT) From: Christoph Lameter Subject: Re: [PATCH 00 of 41] Transparent Hugepage Support #17 In-Reply-To: <4BBB6FEC.9050205@redhat.com> Message-ID: References: <20100405232115.GM5825@random.random> <20100406011345.GT5825@random.random> <4BBB052D.8040307@redhat.com> <4BBB2134.9090301@redhat.com> <20100406131024.GA5288@laptop> <4BBB359D.1020603@redhat.com> <20100406134539.GC5288@laptop> <20100406165031.GA5825@random.random> <4BBB6FEC.9050205@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org To: Avi Kivity Cc: Andrea Arcangeli , Nick Piggin , Linus Torvalds , Pekka Enberg , Ingo Molnar , 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 , Chris Wright , bpicco@redhat.com, KOSAKI Motohiro , Balbir Singh , Arnd Bergmann , "Michael S. Tsirkin" , Peter Zijlstra , Johannes Weiner , Daisuke Nishimura List-ID: On Tue, 6 Apr 2010, Avi Kivity wrote: > On 04/06/2010 07:50 PM, Andrea Arcangeli wrote: > > On Tue, Apr 06, 2010 at 11:45:39PM +1000, Nick Piggin wrote: > > > > > problems. Speedups like Linus is talking about would refer to ways to > > > speed up actual workloads, not ways to avoid fundamental limitations. > > > > > > Prefetching, memory parallelism, caches. It's worked for 25 years :) > > > > > This will always give you a worst case additional 6% on top (gcc is a > > definitive worst case) of all other speedup of the actual workloads, > > for server loads more likely>=15% boost. It's plain underclocking > > your CPU not to run this. > > > > I don't think gcc is worst case. Workloads that benefit from large pages are > those with bloated working sets that do a lot of pointer chasing and do little > computation in between. gcc fits two out of three (just a partial score on > the first). Once you have huge pages you will likely start to optimize for locality. Pointer chasing is bad even with huge pages if you go between multiple huge pages and you are beyond the number of huge tlb entries supported by the cpu. -- 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