Messages in this thread | | | Subject | further.. | Date | Wed, 31 Jul 1996 15:54:56 +0800 | From | "Michael O'Reilly" <> |
| |
After 5.5 hours running the patch to get_empty_filp() posted earlier, profile is now showing the top functions as......
[ ... ] 00122690 sync_buffers 13365 33.7500 2.59 00137650 dev_tint 15681 105.9527 3.04 001376e4 dev_ifconf 16710 72.0259 3.24 0011b534 filemap_nopage 18389 26.8845 3.56 001a0250 vortex_rx 18855 36.2596 3.65 0011af64 generic_file_read 20578 13.8293 3.98 00118be8 do_no_page 20953 25.0634 4.06 00195fc8 stli_write 23428 24.7131 4.54 00137518 dev_transmit 31039 705.4318 6.01 0014bca0 ip_chk_addr 58691 232.9008 11.36
(last column is percentage of total kernel CPU this function is using).
get_empty_filp() is now down to 0.17% of total kernel CPU, down from 16%. So for my usage patterns at least, it's now approx 100 times faster. Anyone else running a profiled kernel in a production environment to compare against?
One of the questions that keeps popping up is: Why is dev_transmit using so much CPU time? as far as I can see, it only get called from net_bh(), and net_bh is only using 0.38%. dev_transmit is basically a loop around dev_tint(), and even dev_tint isn't using that much, even tho it's a much more complex function. Very very odd. Anyone got any ideas on why it's using so much? Note that on the numbers above, dev_transmit() is using 1.6% of wall clock time!
Also, has anyone ever managed to compile a call tracer into the kernel? i.e. something like the equivilant of gprof()? Doesn't look too hard as far as I can see, but I don't know how gcc -p would handle in-lined assembly (and vice versa).
Michael.
(ps. be aware that this machine has (currently) 214 network interfaces. which is why ip_chk_addr is so large)
| |