[lkml]   [2002]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH] Rmap speedup
On Monday 05 August 2002 01:33, Andrew Morton wrote:
> OK, I warmed the code up a bit and did some more measurement.
> Your locking patch has improved things significantly. And
> we're now getting hurt by all the cache misses walking the
> pte chains.

Well that's a relief. I was beginning to believe that your 4 way has some
sort of built-in anti-optimization circuit.

Are you still seeing no improvement on four way smp?

> ...And it's all really in __page_remove_rmap, kmem_cache_alloc/free.
> If we convert the pte_chain structure to
> struct pte_chain {
> struct pte_chain *next;
> pte_t *ptes[L1_CACHE_BYTES - 4];
> };
> and take care to keep them compacted we shall reduce the overhead
> of both __page_remove_rmap and the slab functions by up to 7, 15
> or 31-fold, depending on the L1 size. page_referenced() wins as well.
> Plus we almost halve the memory consumption of the pte_chains
> in the high sharing case. And if we have to kmap these suckers
> we reduce the frequency of that by 7x,15x,31x,etc.
> I'll code it tomorrow.

Sounds good. There is still some tuning to be done on the rmap lock
batching, to distribute the locks better and set anon page->indexes more
intelligently. I expect this to be good for another percent or two, nothing
really exciting.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

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