101 lines
5.4 KiB
HTML
101 lines
5.4 KiB
HTML
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
|
||
<html>
|
||
<head>
|
||
<meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type">
|
||
<title>Profiling & Benchmarking</title>
|
||
<meta name="generator" content="DocBook XSL Stylesheets V1.40">
|
||
<link rel="home" href="index.html" title="Kernel Hacking HOWTO">
|
||
<link rel="up" href="index.html" title="Kernel Hacking HOWTO">
|
||
<link rel="previous" href="indexs09.html" title="Kernel Debugging">
|
||
<link rel="next" href="indexs11.html" title="The Linux Kernel Development Cycle">
|
||
</head>
|
||
<body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF">
|
||
<div class="navheader">
|
||
<table width="100%" summary="Navigation header">
|
||
<tr><th colspan="3" align="center">Profiling & Benchmarking</th></tr>
|
||
<tr>
|
||
<td width="20%" align="left">
|
||
<a href="indexs09.html">Prev</a> </td>
|
||
<th width="60%" align="center"> </th>
|
||
<td width="20%" align="right"> <a href="indexs11.html">Next</a>
|
||
</td>
|
||
</tr>
|
||
</table>
|
||
<hr>
|
||
</div>
|
||
<div class="sect1">
|
||
<a name="profiling"></a><div class="titlepage"><div><h2 class="title" style="clear: both">
|
||
<a name="profiling"></a>Profiling & Benchmarking</h2></div></div>
|
||
<div class="sect2">
|
||
<a name="whyprofile"></a><div class="titlepage"><div><h3 class="title">
|
||
<a name="whyprofile"></a>Why profile?</h3></div></div>
|
||
<p>Naturally, you should aim for efficiency by design and by writing tight code. Profiling is done to locate sections of code that are called most often and/or consume the most CPU time. Optimisation effort can then be focused on those routines, giving the best return on the time invested. If you have never profiled code before, it would be an idea to get acquainted with gprof, a typical userspace command line profiler.</p>
|
||
<p>Just as it is poor practice to rely on a debugger to catch bad code, so it is bad practice to rely on a profiler to catch inefficient code.</p>
|
||
</div>
|
||
<div class="sect2">
|
||
<a name="basicprofiling"></a><div class="titlepage"><div><h3 class="title">
|
||
<a name="basicprofiling"></a>Basic profiling</h3></div></div>
|
||
<p>The kernel has some built in profiling functionality. If you add profile=1 to your kernel command line arguments, then you get a file: <tt>proc/profile</tt> which can be used by readprofile to print profiling information to standard output. Example output from readprofile:</p>
|
||
<pre class="screen">
|
||
$readprofile
|
||
2 stext 0.0500
|
||
514867 default_idle 12871.6750
|
||
1 copy_thread 0.0071
|
||
1 restore_sigcontext 0.0030
|
||
2 system_call 0.0312
|
||
2 handle_IRQ_event 0.0227
|
||
13 do_page_fault 0.0111
|
||
1 schedule 0.0012
|
||
1 wake_up_process 0.0132
|
||
1 copy_mm 0.0014
|
||
-------8---Snip---8-----------------
|
||
</pre>
|
||
<p>The first column contains the number of clock ticks spent in a function (second column), while the third column gives the normalised load; the number of clock ticks divided by the length of the function.</p>
|
||
<p>See <b>man readprofile</b> for details and useful examples. readprofile is usually part of the <tt>util-linux</tt> package. Sometimes readprofile is kept in <tt>/usr/sbin</tt>, so you may need to add that directory to your <b>PATH</b> or soft link it to some directory that is in your path, e.g. <tt>/usr/bin</tt>.</p>
|
||
<p>Note that if you want to carry out profiling on a remote machine, you will need to copy <tt>System.map</tt> and <tt>vmlinux</tt> across to <tt>/usr/src/linux</tt> from the top level source directory where the running kernel was compiled.</p>
|
||
<p>For more information on benchmarking, see the <a href="http://www.linuxdoc.org/HOWTO/Benchmarking-HOWTO.html" target="_top">benchmarking-HOWTO</a>
|
||
</p>
|
||
<div class="sect2">
|
||
<a name="profiletask"></a><div class="titlepage"><div><h3 class="title">
|
||
<a name="profiletask"></a>Your turn</h3></div></div>
|
||
<p>Using the information in this chapter, profile your system carrying out an intensive task such as:</p>
|
||
<div class="itemizedlist"><ul>
|
||
<li><p>
|
||
<a name="id46574887"></a>Running <b>find</b> on the root directory to locate a particular file. Compare with running <b>updatedb</b> followed by <b>locate</b>
|
||
</p></li>
|
||
<li><p>
|
||
<a name="id46574903"></a>Opening multiple heavy weight apps e.g. <b>mozilla</b>, <b>OpenOffice</b>, <b>nautilus</b>, use top to make sure you have driven your system into swapping out to disk.</p></li>
|
||
<li><p>
|
||
<a name="id46574921"></a>Playing a high resolution mpeg video using your favourite media player.</p></li>
|
||
<li><p>
|
||
<a name="id46574925"></a>Compiling a small application</p></li>
|
||
<li><p>
|
||
<a name="id46574929"></a>Compiling a kernel</p></li>
|
||
<li><p>
|
||
<a name="id46574933"></a>If possible try and simulate a heavy network load.</p></li>
|
||
</ul></div>
|
||
<p>The idea here is to get an understanding of the places that the kernel spends most of its time during everyday operations.</p>
|
||
<p>Now using <b>lxr</b> (or some other source code navigation tool), locate the most referenced functions, get familiar with them and try and understand what each function does.</p>
|
||
</div>
|
||
</div>
|
||
</div>
|
||
<div class="navfooter">
|
||
<hr>
|
||
<table width="100%" summary="Navigation footer">
|
||
<tr>
|
||
<td width="40%" align="left">
|
||
<a href="indexs09.html">Prev</a> </td>
|
||
<td width="20%" align="center"><a href="index.html">Home</a></td>
|
||
<td width="40%" align="right"> <a href="indexs11.html">Next</a>
|
||
</td>
|
||
</tr>
|
||
<tr>
|
||
<td width="40%" align="left">Kernel Debugging </td>
|
||
<td width="20%" align="center"><a href="index.html">Up</a></td>
|
||
<td width="40%" align="right"> The Linux Kernel Development Cycle</td>
|
||
</tr>
|
||
</table>
|
||
</div>
|
||
</body>
|
||
</html>
|