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 ESMTP id 461D26B01EE for ; Tue, 6 Apr 2010 05:08:45 -0400 (EDT) Date: Tue, 6 Apr 2010 11:08:13 +0200 From: Ingo Molnar Subject: Re: [PATCH 00 of 41] Transparent Hugepage Support #17 Message-ID: <20100406090813.GA14098@elte.hu> References: <20100405193616.GA5125@elte.hu> <20100405232115.GM5825@random.random> <20100406011345.GT5825@random.random> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: owner-linux-mm@kvack.org To: Linus Torvalds Cc: Andrea Arcangeli , Pekka Enberg , Andrew Morton , 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: * Linus Torvalds wrote: > On Mon, 5 Apr 2010, Linus Torvalds wrote: > > > > So I thought it was a more interesting load than it was. The > > virtualization "TLB miss is expensive" load I can't find it in myself to > > care about. "Get a better CPU" is my answer to that one, > > [ Btw, I do realize that "better CPU" in this case may be "future CPU". I > just think that this is where better TLB's and using ASID's etc is > likely to be a much bigger deal than adding VM complexity. Kind of the > same way I think HIGHMEM was ultimately a failure, and the 4G:4G split > was an atrocity that should have been killed ] Both highmem and 4g:4g were failures (albeit highly practical failures you have to admit) in the sense that their relevance faded over time. (because they extended the practical limits of the constantly fading, 32-bit world.) Both highmem and 4g:4g became less and less of an issue as hardware improved. OTOH are you saying the same thing about huge pages? On what basis? Do you think it would be possible for hardware to 'discover' physically-continuous 2M mappings and turn them into a huge TLB internally? [i'm not sure it's feasible even in future CPUs - and even if it is, the OS would still have to do the defrag and keep-them-2MB logic internally so there's not much difference.] The numbers seem rather clear: http://lwn.net/Articles/378641/ Yes, some of it is benchmarketing (most benchmarks are), but a significant portion of it isnt: HPC processing, DB workloads and Java workloads. Hugepages provide a 'final' performance boost in cases where there's no other software way left to speed up a given workload. The goal of Andrea's and Mel's patch-set, to make this 'final performance boost' more practical seems like a valid technical goal. We can still validly reject it all based on VM complexity (albeit the VM people wrote both the defrag part and the transparent usage part so all the patches are all real), but how can we legitimately reject the performance advantage? I think the hugetlb situation is more similar to the block IO transition to larger sector sizes in block IO or to the networking IO transition from host-side-everything to checksum-offload and then to TSO - than it is similar to highmem or 4g:4g. In fact the whole maintenance thought process seems somewhat similar to the TSO situation: the networking folks first rejected TSO based on complexity arguments, but then was embraced after some time. Ingo -- 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