下記の出力例は、実行中のprelink -aプロセスに関するものである。これを見ると、ここでのレイテンシ情報を取得した時点において、prelinkに関しては最適化を必要とするほどのレイテンシが生じていないことが分かる。この場合、レイテンシ最大のイベントはいずれもディスクIO関連のものとなっているが、そもそもprelinkで行われるメインの処理はIO呼び出しに関する操作であり、そこでの処理完了を待機する関係上、これは想定内の結果としていいはずだ。なお、本稿を執筆する際に使用したシステムに関してのみ言うと、“waiting for cpu”と表示されたプロセスはいずれも10から40ミリ秒（msec）の範囲に収まっていたが、この範囲内での分布についてはかなりランダムに分散した状況となっていた。
Process prelink (7965) Total: 288.0 msec ... Scheduler: waiting for cpu 42.2 msec 30.0 % Writing a page to disk 18.2 msec 52.6 % Walking directory tree 17.9 msec 10.4 % Pagecache sync readahead 12.1 msec 4.2 % EXT3: Waiting for journal access 5.2 msec 1.8 % Reading from a pipe 2.9 msec 1.0 %
アプリケーションがスムースに実行されない場合、システムないしネットワークのどの部分が原因となっているかを特定する上で、レイテンシ発生時にどのカーネル関数が呼び出されているかの特定が、有用な情報となるケースが往々にして存在する。特に最近は、X11リソース用のxrestopおよび有名なPowerTOPツールなど、“top”ライクなツールが多数公開されるようになっている。そうしたツール群の中におけるLatencyTOPの位置付けについては、個々のシステムにおける最大のレイテンシ発生源を簡単に特定するためのツールという評価ができるはずだ。
Ben Martinは10年以上にわたってファイルシステムに取り組んでおり、博士課程の修了後、現在はlibferris、ファイルシステム、検索ソリューションを中心としたコンサルティング業に従事している。