Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: [PATCH] Rmap speedup | Date | Mon, 5 Aug 2002 02:35:27 +0200 |
| |
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.
-- 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/
| |