From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161228AbXDEGKP (ORCPT ); Thu, 5 Apr 2007 02:10:15 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1161232AbXDEGKP (ORCPT ); Thu, 5 Apr 2007 02:10:15 -0400 Received: from gw1.cosmosbay.com ([86.65.150.130]:47893 "EHLO gw1.cosmosbay.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1161228AbXDEGKN (ORCPT ); Thu, 5 Apr 2007 02:10:13 -0400 Message-ID: <461492A5.1030905@cosmosbay.com> Date: Thu, 05 Apr 2007 08:09:41 +0200 From: Eric Dumazet User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Nick Piggin CC: Peter Zijlstra , Andrew Morton , Jakub Jelinek , Ulrich Drepper , Andi Kleen , Rik van Riel , Linux Kernel , linux-mm@kvack.org, Hugh Dickins Subject: Re: missing madvise functionality References: <46128051.9000609@redhat.com> <46128CC2.9090809@redhat.com> <20070403172841.GB23689@one.firstfloor.org> <20070403125903.3e8577f4.akpm@linux-foundation.org> <4612B645.7030902@redhat.com> <20070403202937.GE355@devserv.devel.redhat.com> <20070403144948.fe8eede6.akpm@linux-foundation.org> <4612DCC6.7000504@cosmosbay.com> <46130BC8.9050905@yahoo.com.au> <1175675146.6483.26.camel@twins> <461367F6.10705@yahoo.com.au> <20070404113447.17ccbefa.dada1@cosmosbay.com> <46137882.6050708@yahoo.com.au> <20070404135458.4f1a7059.dada1@cosmosbay.com> <4614585F.1050200@yahoo.com.au> In-Reply-To: <4614585F.1050200@yahoo.com.au> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-1.6 (gw1.cosmosbay.com [86.65.150.130]); Thu, 05 Apr 2007 08:09:50 +0200 (CEST) Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Nick Piggin a écrit : > Eric Dumazet wrote: > >> This was not a working patch, just to throw the idea, since the >> answers I got showed I was not understood. >> >> In this case, find_extend_vma() should of course have one struct >> vm_area_cache * argument, like find_vma() >> >> One single cache on one mm is not scalable. oprofile badly hits it on >> a dual cpu config. > > Oh, what sort of workload are you using to show this? The only reason > that I > didn't submit my thread cache patches was that I didn't show a big enough > improvement. > Database workload, where the user multi threaded app is constantly accessing GBytes of data, so L2 cache hit is very small. If you want to oprofile it, with say a CPU_CLK_UNHALTED:5000 event, then find_vma() is in the top 5. Each time oprofile has an NMI, it calls find_vma(EIP/RIP) and blows out the target process cache (usually plugged on the data vma containing user land futexes). Event with private futexes, it will probably be plugged on the brk() vma.