Some 8-quad numbers for 2.5.37 (virgin) follow.
I'll get dcache_rcu and NUMA sched stuff in on the act for round 2.
This is more fs transaction-based (and VM process-spawning overhead)
and not pure I/O throughput so there won't be things like "but
everybody's running at peak I/O bandwidth" obscuring the issues.
real 0m30.854s
c01053ec 16963617 89.009 poll_idle
c0114a48 452526 2.37443 load_balance
c013962c 253666 1.331 get_page_state
c01466de 177354 0.930586 .text.lock.file_table
c0114ec0 150583 0.790117 scheduler_tick
c01547b3 116144 0.609414 .text.lock.namei
c01422ac 94042 0.493444 page_remove_rmap
c0138c24 83293 0.437043 rmqueue
c0141e48 51963 0.272653 page_add_rmap
c012d5ec 37086 0.194592 do_anonymous_page
c01391d0 34454 0.180782 __alloc_pages
c0130e08 32111 0.168488 find_get_page
c0139534 29222 0.153329 nr_free_pages
c012df4c 26734 0.140275 handle_mm_fault
c0146070 25881 0.135799 get_empty_filp
c01a0d2c 25250 0.132488 __generic_copy_from_user
c0111728 22018 0.11553 smp_apic_timer_interrupt
c0112b90 20777 0.109018 pfn_to_nid
c0136238 18410 0.0965983 kmem_cache_free
c0113270 17494 0.091792 do_page_fault
c0138900 17282 0.0906796 __free_pages_ok
c01a0f90 17160 0.0900395 atomic_dec_and_lock
c01a100b 16937 0.0888694 .text.lock.dec_and_lock
-
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/