lkml.org 
[lkml]   [2002]   [Aug]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [PATCH] Rmap speedup
Date
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/

\
 
 \ /
  Last update: 2005-03-22 13:27    [W:0.135 / U:0.020 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site