lkml.org 
[lkml]   [1996]   [Aug]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: More kernel profiling
Date
From

> After seeing the improvements which resulted the last time someone posted
> a kernel profile to this mailing list, I decided to see if I could continue
> the trend by posting another one :-)
>
> The following is from a 2.0.10 kernel which is doing a large amount of
> compiling . The .o files produced by the compiler are stored on a local disk,
> but the library and executable files are written back out to the NFS file
> system.


[ ... ]
> 429 page_fault 26.8125
> 1581 unplug_device 32.9375
> 3417 nfs_lookup_cache_refresh 35.5938
> 20189 wd_block_output 114.7102

No, you're off the mark here. You're reading the output of readprofile
wrong. That floating point number is actually the number of counts,
divided by the size of the routine, which produces a number, but
probably isn't a very useful number (at least, I couldn't think of a
use for it. :)

What you want is the use a script something like the one
below. Basically, you sort on the number of counts, and then generate
percentages from that. I call this munch, and it as './munch | tail
-20' to find my top 20 users of CPU time. It's a junky hack, but gives
you some numbers that actually mean a bit.

#! /bin/sh
./readprofile -p $1 -m ./System.map -v | sort -n +2 > /tmp/rp.out
perl -e 'open S, "/tmp/rp.out";
while (<S>) { split; $sum += $_[2]; }
close S; open S, "/tmp/rp.out";
while (<S>) {
chop; split; printf "$_\t%.2f\n", ($_[2]/$sum * 100);
}'




Michael.


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.038 / U:0.792 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site