I'm trying to spot a defect part in the disk system on my fileserver,
so I have it running a "dd if=/dev/ad$i of=/dev/null bs=8k" on five
disks in parallel.
I noticed that this maxed out the CPU, so just to see what the kernel
does these days I compiled it with BB profiling [gcc -a, kernbb(8)]
and chewed on the results:
This shows the number of instruction bytes executed and the function
which gcc attributes them to when compiling with "-g".
Notice that some instruction bytes take longer time than others,
it is not a perfect profiling metric, but it surely says something
about where we spend our time.
I'm sufficiently surprised about "spec_vnoperate" that I have decided
to optimise the devfs case for that one.
"getit" is from DELAY() I belive.
Others may be able to spot other targets...
Poul-Henning
43314522342 syscall
35476414198 lockmgr
26753579584 mi_switch
20904413945 physio
20333807164 malloc
19337589607 vn_lock
17724084938 runq_choose
15929363151 msleep
15364410648 spec_vnoperate
14355436178 getit
13428877523 free
11662243674 vn_write
11496265116 vmapbuf
10938192056 ata_command
10848043095 ithread_loop
10658496236 userret
10609126320 runq_add
10469852242 ad_transfer
10249427241 vop_defaultop
10223597353 ad_start
9975983756 ata_start
9546146090 ast
9509717091 vn_read
9238990643 ata_pci_intr
9162859512 vop_nolock
8566282023 vunmapbuf
8557887753 microuptime
8533461738 CURSIG
8387454602 DELAY
8385171377 acquire
8343541335 ata_dmasetup
8137941068 wakeup
8098507767 ad_interrupt
7893890988 ithread_schedule
7537697787 _mtx_lock_sleep
7307547811 fdrop
7187739800 ata_intr
6954550589 ata_dmastart
6932116048 dscheck
6644124113 makedev
6588257835 callout_reset
6510407718 callout_stop
6273610563 dofilewrite
--
Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
[EMAIL PROTECTED] | TCP/IP since RFC 956
FreeBSD committer | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
