You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implement performance event group management and reading enhancements
- Introduced functions to manage performance event groups, including detection of maximum events and validation of static groups.
- Added support for new performance read functions: `read_raw`, `read_details`, and `read_group`, along with their corresponding structures and handling in the code generation.
- Enhanced the type checker to validate performance event group attachments and ensure no cycles exist in group leader relationships.
- Updated userspace code generation to track usage of new performance read functions and manage group attachments.
- Added tests for new functionality, including validation of oversized static performance event groups and code generation for new read functions.
Copy file name to clipboardExpand all lines: BUILTINS.md
+48-3Lines changed: 48 additions & 3 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -98,7 +98,7 @@ fn main() -> i32 {
98
98
-`flags`: Attachment flags (context-dependent)
99
99
- Perf event form:
100
100
-`handle`: Program handle returned from `load()`
101
-
-`opts`: `perf_options` value — only `perf_type` and `perf_config` are required; all other fields have defaults, including `group_fd=-1`
101
+
-`opts`: `perf_options` value — only `perf_type` and `perf_config` are required; all other fields have defaults, including no group (`group` invalid and `group_fd=-1`)
102
102
-`flags`: Must be `0` for perf attaches; nonzero values are rejected
Grouped events are scheduled as one atomic PMU unit. Separate events and separate groups may be multiplexed, but members inside one group cannot be independently multiplexed. Static groups that exceed the target PMU counter limit are rejected at compile time; override the detected/default limit with `KERNELSCRIPT_PERF_GROUP_MAX_EVENTS` when compiling for a different target.
136
+
135
137
**Context-specific implementations:**
136
138
-**eBPF:** Not available
137
139
-**Userspace:** Uses `attach_bpf_program_by_fd` for standard targets and `ks_attach_perf_event` for perf events
@@ -183,7 +185,50 @@ detach(prog) // Clean up
183
185
- Returns a scaled value when `time_running < time_enabled`
184
186
- Returns `-1` on invalid/stale attachment or read failure
185
187
- Reads use the attachment's `perf_fd` directly; the internal token detects copied handles used after detach.
186
-
- Group snapshot reads are not supported yet; read grouped attachments individually.
188
+
- Use `read_group(leader)` when you need a same-time group snapshot.
Adding a member restarts the whole group from zero. Detach members before detaching their leader. `read(att)` still reads one attachment at a time; it returns a multiplex-scaled count when the kernel reports `time_running < time_enabled`. Group snapshot reads are not part of this first-stage API.
333
+
Adding a member restarts the whole group from zero. Detaching a leader cascades to any live members. A group competes for PMU counters as one atomic unit: different groups can be multiplexed over time, but members inside one group are not independently multiplexed. For statically visible groups, the compiler rejects groups that need more PMU counter slots than the target limit. The limit is read from known sysfs PMU caps when available, defaults to 4, and can be overridden with `KERNELSCRIPT_PERF_GROUP_MAX_EVENTS`.
334
+
335
+
`read(att)` returns a multiplex-scaled count when the kernel reports `time_running < time_enabled`. Use `read_raw(att)` for the raw value, `read_details(att)` for raw/scaled/timing details, and `read_group(leader)` for a same-time group snapshot.
-`group: leader_attachment` is the preferred way to join a perf group.
562
569
-`group_fd >= 0` opens the new event as a member of that leader fd.
563
570
- Group members are opened disabled, linked to the BPF program, then the leader is disabled, reset, and enabled with `PERF_IOC_FLAG_GROUP`.
564
571
- Adding a member to an already running group restarts the whole group from zero.
565
-
- Detaching a member is allowed. Detaching a leader while live members reference it is rejected; detach members first.
566
-
- Group snapshot reads are not implemented yet; read each `PerfAttachment` separately.
572
+
- A group is scheduled as an atomic PMU unit. Separate events and separate groups may be multiplexed; members inside one group are not independently multiplexed. If a statically visible group needs more PMU counter slots than the target limit, compilation fails.
573
+
- The compile-time group limit uses known sysfs PMU caps when available, falls back to `4`, and can be overridden with `KERNELSCRIPT_PERF_GROUP_MAX_EVENTS`.
574
+
-`perf_type_software` and `perf_type_tracepoint` do not consume PMU counter slots for this check; static hardware/raw/cache/breakpoint events consume one slot, and dynamic `perf_type` values are conservatively counted as one slot.
575
+
- Detaching a member is allowed. Detaching a leader cascades to any live members.
576
+
-`read_group(leader)` enables `PERF_FORMAT_GROUP | PERF_FORMAT_ID` and returns up to 16 same-time group values plus perf IDs and timing fields.
@@ -583,6 +596,7 @@ For event families with a richer config space, such as `perf_type_hw_cache`, pro
583
596
-`PerfAttachment` carries `perf_fd` plus an internal generation token; `read(attachment)` avoids global attachment-list scans and rejects copied handles after detach
0 commit comments