From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail190.messagelabs.com (mail190.messagelabs.com [216.82.249.51]) by kanga.kvack.org (Postfix) with SMTP id 89E4C6B01F3 for ; Sat, 10 Apr 2010 15:23:39 -0400 (EDT) Message-ID: <4BC0CFF4.5000207@redhat.com> Date: Sat, 10 Apr 2010 22:22:28 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [PATCH 00 of 41] Transparent Hugepage Support #17 References: <20100405232115.GM5825@random.random> <20100406011345.GT5825@random.random> <20100406090813.GA14098@elte.hu> <20100410184750.GJ5708@random.random> <20100410190233.GA30882@elte.hu> In-Reply-To: <20100410190233.GA30882@elte.hu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org To: Ingo Molnar Cc: 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/10/2010 10:02 PM, Ingo Molnar wrote: > * Andrea Arcangeli wrote: > > >> [...] >> >> This is already fully usable and works great, and as Avi showed it boosts >> even a sort on host by 6%, think about HPC applications, and soon I hope to >> boost gcc on host by 6% (and of>15% in guest with NPT/EPT) by extending >> vm_end in 2M chunks in glibc, at least for those huge gcc builds taking >> >>> 200M like translate.o of qemu-kvm... (so I hope soon gcc running on KVM >>> >> guest, thanks to EPT/NPT, will run faster than on mainline kernel without >> transparent hugepages on bare metal). >> > I think what would be needed is some non-virtualization speedup example of a > 'non-special' workload, running on the native/host kernel. 'sort' is an > interesting usecase - could it be patched to use hugepages if it has to sort > through lots of data? > In fact it works well unpatched, the 6% I measured was with the system sort. Currently in order to use hugepages (with the 'always' option) the only requirement is that the application uses a few large vmas. > Is it practical to run something like a plain make -jN kernel compile all in > hugepages, and see a small but measurable speedup? > I doubt it - kernel builds run in relatively little memory. The link stage uses a lot of memory but is fairly fast (I guess due to the partial links before). Building a template-heavy C++ application might show some gains. > Although it's not an ideal workload for computational speedups at all because > a lot of the time we spend in a kernel build is really buildup/teardown of > process state/context and similar 'administrative' overhead, while the true > 'compilation work' is just a burst of a few dozen milliseconds and then we > tear down all the state again. (It's very inefficient really.) > > Something like GIMP calculations would be a lot more representative of the > speedup potential. Is it possible to run the GIMP with transparent hugepages > enabled for it? > I thought of it, but raster work is too regular so speculative execution should hide the tlb fill latency. It's also easy to code in a way which hides cache effects (no idea if it is actually coded that way). Sort showed a speedup since it defeats branch prediction and thus the processor cannot pipeline the loop. I thought ray tracers with large scenes should show a nice speedup, but setting this up is beyond my capabilities. -- 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