Simple Profiler for T-Kernel

[ 日本語 | English ]

Abstract

A simple task profiler for T-Kernel. (Modified to use less memory space compared to previous versions.)

Running environment

T-Kernel/x86 (considered relatively easy to be ported for other architectures)

License

MIT License

Downloads

• Profiler driver (vfdrv.tar.gz) 8KB
• Profiler on/off switch (vfswitch.tar.gz) 4KB
• Profile analyzer (vf.rb) 4KB

How to compile

`vfdrv' and `vfswitch' are driver and process-based application, respectively. Thus, you can compile each of these in $BD/driver/ and $BD/bappl/ directory, respectively.

Usage

1. Execute lodspg vfdrv, so that the profiler driver is loaded.
2. Then execute a program of which profile information you want. There are two options for this:

   A) Hack the target program codes

   Try to understand what vfswitch.tar.gz is doing, and add some codes (i.e. vf_{open,start,stop,save,close}) to start/end profiling like that. Note that you need to add/remove task IDs for multi-task programs.

   B) Trigger profiler from outside, leaving target program unchanged

   Simply execute program, and get the task ID for the target program. (For example by executing "ref tsk".) Let's assume here that the task ID is 123. In that case, start profiling by typing:

   $ vfswitch on 123

   while in order to terminate profiler, type:

   $ vfswitch off

3. Transfer profiler output (/SYS/vf.out) to the host environment.
   Example:

   [/SYS]% fput vf.out 192.168.1.50:/home/takeshi/

4. Lastly, execute analyzer to read the profiler output:

   [takeshi@YashiroRed pcat]$ vf.rb webkit.map vf.out
   [001]     660[ms] ( 86.8%) : sys=100%, usr=  0% : TShellGraphics::drawBitmap(TShellBitmap*, rect const&, rect const&)
   [002]      20[ms] (  2.6%) : sys=100%, usr=  0% : TShellBufferedGraphics::~TShellBufferedGraphics()
   [003]      20[ms] (  2.6%) : sys=100%, usr=  0% : WebCore::Font::drawGlyphs(WebCore::GraphicsContext*, WebCore::SimpleFontData const*, WebCore::GlyphBuffer const&, int, int, WebCore::FloatPoint const&) const
   [004]      20[ms] (  2.6%) : sys=  0%, usr=100% : jscyyparse(void*)
   [005]      10[ms] (  1.3%) : sys=  0%, usr=100% : BMLockTmo
   [006]      10[ms] (  1.3%) : sys=100%, usr=  0% : TShellGraphics::fillRectangle(int, int, int, int)
   [007]      10[ms] (  1.3%) : sys=  0%, usr=100% : WebCore::cssValueKeywordID(WebCore::CSSParserString const&)
   [008]      10[ms] (  1.3%) : sys=  0%, usr=100% : _mem_malloc
   [009]       0[ms] (  0.0%) : sys=  0%, usr=  0% : TShellApp::cycle()
   [010]       0[ms] (  0.0%) : sys=  0%, usr=  0% : TShellWebKitPanel::onWorkAreaMouseDown()

   In the above example output, we can get that most of the time is spent on TShellGraphics::drawBitmap function, and that it is a good idea to select this function as the target you optimize. However, as system time is 100% for this period, this problem cannot be solved simply; instead, it is necessary to change the program structure to reduce the number of calls to time-consuming SVC functions.

How this program works

Mechanism is really simple: vfdrv checks and records PC (program counter) of the target tasks periodically (using cyclic handlers), and then vf.rb analyzes how much time is spent on each functions from these data. This mechanism is similar to sysprof in Linux, although they differ in that sysprof profiles the whole system, while vfdrv focuses on a specified task.

Unlike gprof, this profiler cannot show the number of calls to profiled functions, which cannot be achieved simply by this method. Instead, this profiler can profile kernel-based programs (by specifying tid from outer process), and does not modify any code or binaries.

Notes

• vf.rb sorts the functions by the CPU-time they spent, which means that idle time (e.g. time spent in dly_tsk) is not included in profiling. If you need to get the RTC time duration, you need to modify analyzer to calculate using self_rtime instead.
• vfdrv is implemented primarily for profiling process-based applications: while the task is executing a system call, vfdrv records the PC in the user mode (the PC value just before entering the kernel mode), not the PC in the kernel level. This is because kernel PC has less meaning to user-mode PC when profiling processes, and as the kernel-level *.map file may not be available. So, when you want to profile a kernel-mode applications (like drivers), it is preferable to modify get_instruction_pointer() function to fulfill the needs.
• Cumulative time is not measured in current implementations. (cumu_* are all 0.) Supporting this remains as a future work.
• There might be some bugs, as data structure in vfdrv became complex compare to the previous versions.
• I know that this software should be implemented as a subsystem. But I implemented as a driver because it was much simpler. When I became unsatisfied with the current one, I might change that way.
• The prefix `VF' for functions and filenames for this software comes from "Vogelfänger". As the browser implemented prior to this were named after the opera "Zauberflöte", I took something related to it for this software as well.

[ Back ]

Last modified: Fri Nov 25 06:57:31 2011