Glossary of OProfile source concepts and types

application image

The primary binary image used by an application. This is derived from the kernel and corresponds to the binary started upon running an application: for example, /bin/bash.

binary image

An ELF file containing executable code: this includes kernel modules, the kernel itself (a.k.a. vmlinux), shared libraries, and application binaries.


Short for "dentry cookie". A unique ID that can be looked up to provide the full path name of a binary image.

dependent image

A binary image that is dependent upon an application, used with per-application separation. Most commonly, shared libraries. For example, if /bin/bash is running and we take some samples inside the C library itself due to bash calling library code, then the image /lib/ would be dependent upon /bin/bash.


This refers to the ability to merge several distinct sample files into one set of data at runtime, in the post-profiling tools. For example, per-thread sample files can be merged into one set of data, because they are compatible (i.e. the aggregation of the data is meaningful), but it's not possible to merge sample files for two different events, because there would be no useful meaning to the results.

profile class

A collection of profile data that has been collected under the same class template. For example, if we're using opreport to show results after profiling with two performance counters enabled profiling DATA_MEM_REFS and CPU_CLK_UNHALTED, there would be two profile classes, one for each event. Or if we're on an SMP system and doing per-cpu profiling, and we request opreport to show results for each CPU side-by-side, there would be a profile class for each CPU.

profile specification

The parameters the user passes to the post-profiling tools that limit what sample files are used. This specification is matched against the available sample files to generate a selection of profile data.

profile template

The parameters that define what goes in a particular profile class. This includes a symbolic name (e.g. "cpu:1") and the code-usable equivalent.