The Harvester gathers task samples from jobs, processes, and threads on the Fuchsia device. This document describes how the data is labeled and what the values represent.
The path to each sample includes koid, the kernel object ID (koid), and the sample name. For example, koid:12345:zircon-services.
Data collected by the Harvester along with timestamp and a Dockyard path is called a sample. The following sections describe Task samples collected. They are presented in three groups, some values (for example, name) appear in multiple groups.
A job has permissions. A job has one or more processes (which have memory mappings), and each process has one or more thread (which execute on a CPU).
This is always dockyard::KoidType::JOB for a job.
The koid of the object that started this job.
A UTF-8 string label for the job. May not be unique.
If the Fuchsia device is low on memory (that is, oom or Out Of Memory), this job (and its child processes and their threads) may be ‘killed’ (that is, terminated) for the good of the rest of the system. For example, the job is not critical. A Boolean value, 1 is true (will be killed) and 0 is false.
A process has memory. In contrast, a thread accesses memory owned by the Process, but threads themselves don't have their own (memory) address range.
A byte of memory is considered committed if it's backed by physical memory. Some of the memory may be double-mapped, and thus double-counted. Samples where this may occur are marked “May be counted by more than one mapping” below.
This is always dockyard::KoidType::PROCESS for a process.
The koid of the object that started this process (for example, its job).
A UTF-8 string label for the job. May not be unique.
The total size of mapped memory ranges in the process, though not all is backed by physical memory.
Committed memory that is only mapped into this process. May be counted by more than one mapping.
Committed memory that is mapped into this and at least one other process. May be counted by more than one mapping.
An estimate of the prorated number of mem_shared_bytes used by this process.
Calculated by:
For each shared, committed byte,
memory_scaled_shared_bytes += 1 / (number of process mapping this byte)`
memory_scaled_shared_bytes is smaller than memory_shared_bytes. May be counted by more than one mapping.
See zx_info_task_stats_t in zircon/system/public/zircon/syscalls/object.h for up-to-date information.
A thread exists within a process and each process will have at least one thread. Threads actually execute (use the CPU) while a process does not.
A thread does not have its own memory address space. Instead threads use the memory address space of their parent process.
This is always dockyard::KoidType::THREAD for a thread.
The koid of the object that started this thread (for example, its process).
A UTF-8 string label for the job. May not be unique.
Whether the thread is running, waiting, and so on. The current (when this was written) thread states are:
Basic thread states, in zx_info_thread_t.state. ZX_THREAD_STATE_NEW 0x0000 ZX_THREAD_STATE_RUNNING 0x0001 ZX_THREAD_STATE_SUSPENDED 0x0002 // ZX_THREAD_STATE_BLOCKED is never returned by itself. // It is always returned with a more precise reason. // See ZX_THREAD_STATE_BLOCKED_* below. ZX_THREAD_STATE_BLOCKED 0x0003 ZX_THREAD_STATE_DYING 0x0004 ZX_THREAD_STATE_DEAD 0x0005 More precise thread states. ZX_THREAD_STATE_BLOCKED_EXCEPTION 0x0103 ZX_THREAD_STATE_BLOCKED_SLEEPING 0x0203 ZX_THREAD_STATE_BLOCKED_FUTEX 0x0303 ZX_THREAD_STATE_BLOCKED_PORT 0x0403 ZX_THREAD_STATE_BLOCKED_CHANNEL 0x0503 ZX_THREAD_STATE_BLOCKED_WAIT_ONE 0x0603 ZX_THREAD_STATE_BLOCKED_WAIT_MANY 0x0703 ZX_THREAD_STATE_BLOCKED_INTERRUPT 0x0803 ZX_THREAD_STATE_BLOCKED_PAGER 0x0903
See zircon/system/public/zircon/syscalls/object.h for an up-to-date reference.
A channel provides a means of FIDL communication between processes.
For each pair of processes using channels for IPC, a pair of channels is created. Channels are always created by the kernel in pairs. Two channels can be tied together using the koid of the peer channel.
This is always dockyard::KoidType::CHANNEL for a channel.
* refers to the koid of the process that holds the channel.
* refers to the koid of the channel that communicates with this channel. Normally there is a complementary entry referring back to this channel.