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.
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.
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/libc.so
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.
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.
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.
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.