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...


   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

Reply via email to