Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Sat, 3 Aug 2002 17:02:14 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Sat, 3 Aug 2002 17:02:14 -0400 Received: from garrincha.netbank.com.br ([200.203.199.88]:20996 "HELO garrincha.netbank.com.br") by vger.kernel.org with SMTP id ; Sat, 3 Aug 2002 17:02:06 -0400 Date: Sat, 3 Aug 2002 18:05:12 -0300 (BRT) From: Rik van Riel X-X-Sender: riel@imladris.surriel.com To: Andrew Morton cc: Daniel Phillips , Subject: Re: [PATCH] Rmap speedup In-Reply-To: <3D4B692B.46817AD0@zip.com.au> Message-ID: X-spambait: aardvark@kernelnewbies.org X-spammeplease: aardvark@nl.linux.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1016 Lines: 31 On Fri, 2 Aug 2002, Andrew Morton wrote: > No joy, I'm afraid. > Guess we should instrument it up and make sure that the hashing > and index thing is getting the right locality. Could it be that your quad needs to go to RAM to grab a cacheline that's exclusive on the other CPU while Daniel's machine can just shove cachelines from CPU to CPU ? What I'm referring to is the fact that the pte_chain_locks in Daniel's patch are all packed into a few cachelines, instead of having each lock on its own cache line... This could explain the fact that the locking overhead plummeted on Daniel's box while it didn't change at all on your machine. regards, Rik -- Bravely reimplemented by the knights who say "NIH". http://www.surriel.com/ http://distro.conectiva.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/