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 80A616B01E3 for ; Sat, 10 Apr 2010 16:22:13 -0400 (EDT) Received: by pwi2 with SMTP id 2so3637772pwi.14 for ; Sat, 10 Apr 2010 13:22:12 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <20100410200037.GO5708@random.random> References: <20100405232115.GM5825@random.random> <20100406011345.GT5825@random.random> <20100406090813.GA14098@elte.hu> <20100410184750.GJ5708@random.random> <20100410190233.GA30882@elte.hu> <4BC0CFF4.5000207@redhat.com> <20100410194751.GA23751@elte.hu> <20100410200037.GO5708@random.random> From: Jason Garrett-Glaser Date: Sat, 10 Apr 2010 13:21:52 -0700 Message-ID: Subject: Re: [PATCH 00 of 41] Transparent Hugepage Support #17 Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org To: Andrea Arcangeli Cc: Ingo Molnar , Avi Kivity , Mike Galbraith , Linus Torvalds , Pekka Enberg , Andrew Morton , linux-mm@kvack.org, Marcelo Tosatti , Adam Litke , Izik Eidus , Hugh Dickins , Nick Piggin , 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: >> (i've Cc:-ed x264 benchmarking experts - in case i missed something) > > It definitely worth trying... nice idea. But we need glibc to increase > vm_end in 2M aligned chunk, otherwise we've to workaround it in the > kernel, for short lived allocations like gcc to take advantage of > this. I managed to get 200M of gcc (of ~500M total) of translate.o > into hugepages with two glibc params, but I want it all in transhuge > before I measure it. I'm running it on the workstation that had 1 day > and half of uptime and it's still building more packages as I write > this and running large vfs loads in /usr and maildir. > Just an FYI on this--if you're testing x264, it performs _all_ memory allocation on init and never mallocs again, so it's a good testbed for something that uses a lot of memory but doesn't malloc/free a lot. Jason -- 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