Date: Tue, 20 Mar 2001 15:35:33 +0100 From: Poul-Henning Kamp <phk@freebsd.org> To: current@freebsd.org Subject: some -current profile data... Message-ID: <71310.985098933@critter>
next in thread | raw e-mail | index | archive | help
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 phk@FreeBSD.ORG | 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?71310.985098933>