Wow! Is this box NUMA (what latency ratio, mem access speeds, etc?), or can you really build a straight SMP that big?
OK, now I'm going to have to build a bigger system ;-)
> Due to the final link and compress stage, there is a fair amount of idle
> time at the end of the run. Its going to be hard to push that number
> lower by adding cpus.
I think we need to fix the final phase .... anyone got any ideas
on parallelizing that?
> The profile results below show that kernel time is dominated by the low
> level ppc64 pagetable management. We are working to correct this, a lot
> of the overhead in __hash_page should be gone soon. The rest of the
> profile looks pretty good, do_anonymous_page and lru_cache_add show
> up high as they did in Martin's results.
I have some strange plans for the lru stuff, but it'll take me a while.
I'm curious as to why lru_cache_del is so much lower in your list than
add, whereas the ratio for me is about:
719 lru_cache_add 7.8152
477 lru_cache_del 21.6818
> 6714 .local_flush_tlb_range ppc64 specific
> 2773 .local_flush_tlb_page ppc64 specific
Do you know what's causing the tlb flushes? Just context switches?
> 554 .d_lookup
Did you try the dcache patches?
Can you publish lockmeter stats?
Thanks,
M.
-
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/