From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by kanga.kvack.org (Postfix) with SMTP id C1E1C6B01EE for ; Mon, 12 Apr 2010 07:31:31 -0400 (EDT) Message-ID: <4BC30436.8070001@redhat.com> Date: Mon, 12 Apr 2010 14:29:58 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: hugepages will matter more in the future References: <20100410194751.GA23751@elte.hu> <4BC0DE84.3090305@redhat.com> <4BC0E2C4.8090101@redhat.com> <4BC0E556.30304@redhat.com> <4BC19663.8080001@redhat.com> <4BC19916.20100@redhat.com> <20100411110015.GA10149@elte.hu> <4BC1B034.4050302@redhat.com> <20100411115229.GB10952@elte.hu> <20100412042230.5d974e5d@infradead.org> In-Reply-To: <20100412042230.5d974e5d@infradead.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org To: Arjan van de Ven Cc: Ingo Molnar , Jason Garrett-Glaser , Mike Galbraith , Andrea Arcangeli , 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: On 04/12/2010 02:22 PM, Arjan van de Ven wrote: > >> This is why i think we should think about hugetlb support today and >> this is why i think we should consider elevating hugetlbs to the next >> level of built-in Linux VM support. >> > > I respectfully disagree with your analysis. > While it is true that the number of "level 1" tlb entries has not kept > up with ram or application size, the CPU designers have made it so that > there effectively is a "level 2" (or technically, level 3) in the cache. > > A tlb miss from cache is so cheap that in almost all cases (you can > cheat it by using only 1 byte per page, walking randomly through memory > and having a strict ordering between those 1 byte accesses) it is > hidden in the out of order engine. > Pointer chasing defeats OoO. The cpu is limited in the amount of speculation it can do. Since you will likely miss on the data access, you have two memory accesses to hide (3 for virt). > So in practice, for many apps, as long as the CPU cache scales with > application size the TLB more or less scales too. > A 16MB cache maps 8GB of memory (4GB with virtualization), leaving nothing for data. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. -- 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