Hello, I've done some stat-based kernel profiling (I'll have to post how to do it on the wiki sometime) on ext2fs doing nothing more than
while true; do rm -f blop ; \cp -f blip blop ; done (the file is 2MiB) The results are: thread_will_wait: 11.700000% thread_go: 10.650000% thread_wakeup_prim: 10.250000% assert_wait: 10.000000% thread_block: 9.650000% thread_continue: 8.900000% thread_invoke: 6.550000% vm_map_lookup_entry: 2.900000% ldt_init: 2.250000% pmap_page_protect: 1.750000% thread_handoff: 1.600000% pmap_copy_page: 1.300000% vm_object_deactivate_pages: 1.150000% __mach_msg: 0.800000% hurd_thread_self: 0.700000% vm_map_enter: 0.650000% vm_page_deactivate: 0.550000% ipc_kmsg_copyin_body: 0.550000% zalloc: 0.500000% It might be biaised by the clock not being able to tick everywhere in the kernel (though I guess e.g. most of the IPC machinery is running at ipl0?), but I believe it's still a bit revealing: I had already noticed that ext2fs spends most of its time in the kernel (like 90%), and it here seems we're spending a lot of time just managing the ext2fs thread sleeps (no, there aren't many threads in that test, just two dozen). Samuel
