> From dbench 512 on a 32x NUMA-Q with 32GB of RAM running 2.5.36-mm1:
>
> c015c5c6 4243413 10.742 .text.lock.dcache
> c01317f4 2229431 5.64371 generic_file_write_nolock
> c0130d10 2182906 5.52593 file_read_actor
> c0114f30 2126191 5.38236 scheduler_tick
> c0154b83 1905648 4.82407 .text.lock.namei
> c011749d 1344623 3.40386 .text.lock.sched
> c019f8ab 1102566 2.7911 .text.lock.dec_and_lock
> c01066a8 612167 1.54968 .text.lock.semaphore
> c015ba5c 440889 1.11609 d_lookup
>
> with akpm's removal of lock section directives:
>
> c0114de0 6545861 7.89765 scheduler_tick
> c0151718 4514372 5.44664 path_lookup
> c015ac4c 3314721 3.99924 d_lookup
> c0130560 3153290 3.80448 file_read_actor
> c0131044 2816477 3.39811 generic_file_write_nolock
> c015a8e4 1980809 2.38987 d_instantiate
> c019e1b0 1959187 2.36378 atomic_dec_and_lock
> c0111668 1447604 1.74655 smp_apic_timer_interrupt
> c0159fc0 1291884 1.55867 prune_dcache
> c015a714 1089696 1.31473 d_alloc
> c01062cc 1030194 1.24294 __down
So akpm's removal of lock section directives breaks down the
functions holding locks that previously were reported under the
.text.lock.filename? Looks like fastwalk might not behave so well
on this 32 cpu numa system...
Hanna
-
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/