Messages in this thread |  | | | Subject | Re: 2.1.114 VFS code 5x slower than 2.0.33?!? | | From | Andi Kleen <> | | Date | 07 Aug 1998 22:41:09 +0200 |
| |
Andi Kleen <ak@muc.de> writes:
[hate to follow myself up, but ...]
> I repeated your tests with kernel profiling on 2.1.114: > > Creation: > 28.42user 59.63system 2:18.66elapsed 63%CPU (0avgtext+0avgdata 0maxresident)k > 0inputs+0outputs (710242major+390114minor)pagefaults 0swaps > > ... > 64 1.05% c011ab7c zap_page_range > 68 1.11% c011a9b4 copy_page_range > 81 1.33% c01383e0 ext2_get_group_desc > 95 1.56% c0126134 get_hash_table > 98 1.61% c010ada0 show_registers (this appears often in > other kernel profiles too - anyone know the reason?) > 111 1.82% c013a994 ext2_new_inode > 192 3.16% c011d988 filemap_nopage > 382 6.28% c01396c0 ext2_readdir > 463 7.62% c011b384 do_wp_page > 823 13.54% c013c6e0 ext2_find_entry > 953 15.68% c013ca38 ext2_add_entry > 1263 20.79% c013960c ext2_check_dir_entry ^^^^^^^^^^^^^^^^^^^^^^ This is bogus. ext2_check_dir_entry is just a small function that does some check - it should never take up that much run time. Anyone have any theories on this? Or is my profile hosed, can anyone else reproduce it?
I instrumented my kernel and in about 3h of moderate X11 usage it called ext2_check_dir_entry 1520890 times, which seems a bit high.
-Andi
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html
|  |