About KTAU
This page introduce various aspects of KTAU. More detail information is provided in the KTAU documentation page .
Profiling and Tracing
KTAU can operates in two modes:
Profiling
Currently KTAU provides flat-profiles with inclusive/exclusive times recorded instead of simple interval timers. This enables pin-pointing the actual bottleneck easily. While a call-graph profile may be the best way to isolate bottlenecks, at OS-level it could introduce too much perturbation. Instead a combination of inclusive/excusive timing information and knowledge of source code provides a good trade-off. Profiles are available in TAU profile format and can be viewed in Paraprof. Profiles can also be converted to a number of other formats using TAU's conversion tools. Apart from start-stop timers, events and function call counts are the other profiling primitives provided.
Tracing
Profiling provides aggregated information. For certain uses, more detailed trace-level information is required. For instance, a profile would show how long or how often a program was interrupted. But to be able to see the distribution of interruptions over time or to be able to analyze an existing pattern of interrupts - e.g. most of them clustered around some time/event- trace data is needed. KTAU also provides a trace mode. Trace data is provided in KTAU trace formats, which can be converted to TAU format. This layer of conversion allows KTAU trace to be merged with TAU to provide a complete user-kernel mode trace. Nonetheless, it allows KTAU to use exisiting format-convertion tools available in TAU to convert the trace output into formats supported by other visualization tools such as Vampir and Jumpshot.
KTAU's User-API
A user-library provides API to access KTAU profiles and traces. It also provides a mechanism to merge TAU-user profiles with KTAU's kernel profiles (this merge-API is used only from within TAU). The KTAU user-library is available to any programs (TAU internally uses this same API). The API in-turn uses the proc-filesystem to interface with the KTAU infrastructure inside the kernel. Hence, user-programs are shielded from changes to the KTAU infrastructure or the proc-filesystem protocol.
Application-based vs. Daemon-based Frameworks
The KTAU infrastructure within the kernel takes care of collecting and storing in memory the profiling or tracing information in per-process kernel buffers. There is a KTAU-proc-filesystem interface that is provided to interact (data extraction and control) with KTAU inside the kernel. A KTAU-User API is provided to hide the details of this proc protocol. At some points, some user-mode processes need to extract the kernel information to the user-side through the provided API.
Application-based
As mentioned before, KTAU is developed as a per-process profiling/tracing toolkit whose main aim is to provide accurate characterization of a user-program's behavior inside the kernel and to merge that behavior with user-side profile/trace data. An application process can be responsible for extracting (storing and analyzing) kernel-mode profile/trace. This is achieved by instrumenting the source code of the user-program with KTAU-User API, which extracts the kernel data. Applications can explicitly call to KTAU User-APIs to access profile/trace data at any points. This framework requires that the application source code is available, and is instrumented with calls to access KTAU profile/trace data. TAU uses this framework to access kenel-level profile/trace, which later can be merged with its own profile/trace from application-level. This results in a complete profile/trace information across the kernel-user space.
More detailsDaemon-based
A daemon-based approach is used in instances where the application source is not available , but the kernel-level behavior still needs to be extracted. This is similar to most other kernel profiling/tracing toolkits. KTAUD (KTAU Daemon) is a daemon that can be used to extract profiling or tracing data for any running process periodically. KTAUD is written with the same KTAU user-API, and does not use any special-purpose interfaces. Custom daemons can also be written by users if needed (using KTAUD as a reference). KTAUD can be configured to extract profiling/tracing data for all running processes or a specified subset of them, and write the output to filesystem.
More detailsKTAU Internals
Please refer to internals manual and source code