1. Oprofiles are generated by regularly sampling the current registers on each CPU (from an interrupt handler, the saved PC value at the time of interrupt is stored), and converting that runtime PC value into something meaningful to the programmer.
2.taking the stream of sampled PC values, along with the detail of which task was running at the time of the interrupt, and converting into a file offset against a particular binary file. ( The mmap() function shall establish a mapping between a process’ address space and a file, shared memory object, or [TYM] typed memory object.)
3. In common operation, the time between each sample interrupt is regulated by a fixed number of clock cycles.
4.These hardware performance counters increment once per each event, and generate an interrupt on reaching some pre-defined number of events. OProfile can use these interrupts to generate samples: then, the profile results are a statistical approximation of which code caused how many of the given event.
5. OProfile implements a pseudo-filesystem known as “oprofilefs”, mounted from userspace at
/dev/oprofile. This consists of small files for reporting and receiving configuration from userspace, as well as the actual character device that the OProfile userspace receives samples from.
6. The OProfile userspace daemon’s job is to take the raw data provided by the kernel and write it to the disk.
7. “unit mask” is borrowed from the Intel architectures, and can further specify exactly when a counter is incremented (for example, cache-related events can be restricted to particular state transitions of the cache lines).
All of the available hardware events and their details are specified in the textual files in the
events directory. The syntax of these files should be fairly obvious. The user specifies the names and configuration details of the chosen counters via opcontrol.
8.The actual sample file name is dot-separated, where the fields are, in order: event name, event count, unit mask, task group ID, task ID, and CPU number.
vmlinux), shared libraries, and application binaries.
/bin/bashis running and we take some samples inside the C library itself due to bash calling library code, then the image
/lib/libc.sowould be dependent upon
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.