Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: [PATCH] Rmap speedup | Date | Sat, 3 Aug 2002 23:36:40 +0200 |
| |
On Saturday 03 August 2002 23:05, Rik van Riel wrote: > 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.
To put each lock in its own cacheline:
static inline unsigned rmap_lockno(pgoff_t index) { - return (index >> 4) & (ARRAY_SIZE(rmap_locks) - 1); + return (index >> 4) & (ARRAY_SIZE(rmap_locks) - 64); }
a quick hack, notable mainly for being obscure ;-)
I did try this and noticed scarcely any difference.
-- Daniel - 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/
| |