The Harvester gathers a collection of CPU samples from each CPU on the device. This document describes how the data is labelled and what the values represent.
The path to each sample includes cpu, the processor index, and the sample name. For example,cpu:0:busy_time.
Data collected by the Harvester along with timestamp and a Dockyard path is called a sample. The following sections describe CPU samples collected. They are grouped in four broad categories.
The busy and idle times are complementary. The busy time is derived from the idle time.
The number of main CPUs. For the cpu:*: sample paths the * will be a number from 0 to cpu:count - 1.
The total accumulated time this processor has been busy.
The total accumulated time this processor was not doing work (not running any threads).
The scheduler schedules threads. It determines which thread a given CPU should be running.
How many potential context_switches occurred. All context_switches are preceded by a reschedule, but not all reschedules result in a context_switch.
How many thread switches have occurred. A high value may indicate threads are thrashing (spending an inordinate amount of time switching places rather than doing work).
How many thread preemptions have occurred due to an interrupt (irq) while the CPU is not idle. If the thread is idle the interrupt is not considered meaningful and is not tracked here.
How many thread preemptions have occurred. (Not currently used).
How many times a thread has yielded its use of a processor to allow another thread to execute.
An interrupt causes the current flow of a thread to be “interrupted”. The thread is stopped, the state is preserved (so it can be resumed) and the processor executes an interrupt handler (function).
External hardware interrupts indicate a signal or event happening outside of the machine. Common examples are serial input, or a physical button like a volume up or down button. Does not include timer or inter-processor interrupts.
A timer interrupt occurs when a “clock” (or some kind of time keeping device) creates an interrupt.
How many times a function (callback) has been called due to a timer. Each time a timer interrupt occurs, zero-to-many timer callbacks may be called.
How many system (kernel) API calls have been made.
An inter-processor interrupt occurs when a processor signals another processor.
The count of times the scheduler (running on some CPU) has requested a schedule change (waking up another CPU).
The count of inter-process interrupts that were not a schedule change (tracked as reschedule_ipis), ipi interrupt (untracked), or ipi halt (untracked).