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/
This archive was generated by hypermail 2b29 : Wed Aug 07 2002 - 22:00:22 EST