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 2624D6B01E3 for ; Mon, 5 Apr 2010 16:46:30 -0400 (EDT) Received: by fxm2 with SMTP id 2so1568250fxm.10 for ; Mon, 05 Apr 2010 13:46:28 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: References: <20100405120906.0abe8e58.akpm@linux-foundation.org> <20100405193616.GA5125@elte.hu> Date: Mon, 5 Apr 2010 23:46:27 +0300 Message-ID: Subject: Re: [PATCH 00 of 41] Transparent Hugepage Support #17 From: Pekka Enberg Content-Type: text/plain; charset=ISO-8859-1 Sender: owner-linux-mm@kvack.org To: Linus Torvalds Cc: Ingo Molnar , Andrew Morton , Andrea Arcangeli , linux-mm@kvack.org, Marcelo Tosatti , Adam Litke , Avi Kivity , 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: Hi Linus, On Mon, Apr 5, 2010 at 11:32 PM, Linus Torvalds wrote: >> AFAIK, most modern GCs split memory in young and old generation >> "zones" and _copy_ surviving objects from the former to the latter if >> their lifetime exceeds some threshold. The JVM keeps scanning the >> smaller young generation very aggressively which causes TLB pressure >> and scans the larger old generation less often. > > .. my only input to this is: numbers talk, bullsh*t walks. > > I'm not interested in micro-benchmarks, either. I can show infinite TLB > walk improvement in a microbenchmark. > > In order for me to be interested in any complex hugetlb crap, I want real > numbers from real applications. Not "it takes this many cycles to walk a > page table", or "it could matter under these circumstances". > > I also want those real numbers _not_ directly after a clean reboot, but > after running other real loads on the machine that have actually used up > all the memory and filled it with things like dentry data etc. The "right > after boot" case is totally pointless, since a huge part of hugetlb > entries is the ability to allocate those physically contiguous and > well-aligned regions. > > Until then, it's just extra complexity for no actual gain. > > Oh, and while I'm at it, I want a pony too. Unfortunately I wasn't able to find a pony on Google but here are some huge page numbers if you're interested: http://zzzoot.blogspot.com/2009/02/java-mysql-increased-performance-with.html I'm actually bit surprised you find the issue controversial, Linus. I am not a real JVM hacker (although I could probably play one on TV) but the "hugepages are a big win" argument seems pretty logical for any GC heavy activity. Wouldn't be the first time I was wrong, though. Pekka -- 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