From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail144.messagelabs.com (mail144.messagelabs.com [216.82.254.51]) by kanga.kvack.org (Postfix) with ESMTP id AAE746B01E3 for ; Mon, 5 Apr 2010 16:38:04 -0400 (EDT) Date: Mon, 5 Apr 2010 13:32:21 -0700 (PDT) From: Linus Torvalds Subject: Re: [PATCH 00 of 41] Transparent Hugepage Support #17 In-Reply-To: Message-ID: References: <20100405120906.0abe8e58.akpm@linux-foundation.org> <20100405193616.GA5125@elte.hu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org To: Pekka Enberg 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: On Mon, 5 Apr 2010, Pekka Enberg 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. Linus PS. I also think the current odd anonvma thing is _way_ more important. That was a feature that actually improved AIM throughput by 300%. Now, admittedly that's not a real load either, but at least it's not a total microbenchmark. -- 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