ebpf-performance-engineering

Stars1

Forks0

UpdatedApril 15, 2026 at 04:59

Use when a task requires writing, loading, or reasoning about eBPF programs for Linux performance analysis. Covers tool selection across bpftrace, BCC, and libbpf CO-RE, plus hook choice, build or load steps, map design, verification, and overhead control. Do not trigger for generic Linux perf analysis that can be handled without custom eBPF work.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Source

DarkHighness

DarkHighness/nanoclaw

View GitHub Repository View Creator Repositories

Download

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

File Explorer

4 files

SKILL.md

readonly

name	ebpf-performance-engineering
description	Use when a task requires writing, loading, or reasoning about eBPF programs for Linux performance analysis. Covers tool selection across bpftrace, BCC, and libbpf CO-RE, plus hook choice, build or load steps, map design, verification, and overhead control. Do not trigger for generic Linux perf analysis that can be handled without custom eBPF work.

eBPF Performance Engineering

When to use

Write or adapt an eBPF probe for performance analysis.
Decide whether bpftrace, BCC, or libbpf CO-RE is the right implementation path.
Load, attach, and verify eBPF programs safely on Linux.

Read before implementing

references/toolchain-selection.md for choosing bpftrace, BCC, or libbpf CO-RE.
references/libbpf-core-workflow.md for the standard compile, skeleton, load, attach, and cleanup flow.

Workflow

Start from the measurement question.
- What event, latency, queue, or stack attribution is missing?
- What is the acceptable overhead?
Choose the right implementation level.
- bpftrace: one-liners and short scripts for quick interactive diagnostics.
- BCC: ready-made tools or Python-driven prototypes.
- libbpf CO-RE: version-portable, reusable probes that belong in a repository or product workflow.
Choose the safest hook.
- Prefer tracepoints or fentry/fexit when available.
- Use kprobe/kretprobe only when stable higher-level hooks do not exist.
- Use uprobes or USDT for user-space behavior.
Keep the kernel-side program minimal.
- Filter early.
- Aggregate in maps when possible.
- Emit only the data needed for the question.
- Avoid high-cardinality keys unless the workload and memory budget justify them.
Load and verify deliberately.
- Confirm privileges, kernel support, BTF availability, and toolchain availability.
- Compare eBPF output with perf, sysstat, or known workload events when possible.
Clean up after the run.
- Detach links, remove pinned objects if used, and note any kernel settings changed for the run.

Engineering rules

Favor narrow probes over broad tracing.
Prefer latency histograms, counters, and sampled attribution to verbose per-event logs.
Measure or estimate overhead when event rates are high.
Document the kernel assumptions and required capabilities.

Output expectations

State why eBPF is needed instead of perf or plain counters.
Name the hook, map or buffer strategy, load path, and validation plan.
If implementing code, include build and run instructions.

More from this repository

same repository

sched-ext-build-verify

DarkHighness/nanoclaw

Use when sched-ext source has to be edited, then compiled, verifier-checked, and persisted with concrete artifacts. Covers build command hygiene, libbpf or verifier triage, and script-friendly artifact capture.

2026-04-231

sched-ext-run-evaluation

DarkHighness/nanoclaw

Use when baseline and candidate runs need to be executed and compared with reproducible artifacts instead of free-form notes. Covers repeated runs, metrics import, noise handling, and script-driven comparison instead of host-owned scoring.

2026-04-231

sched-workload-contract

DarkHighness/nanoclaw

Use when a tuning request needs to be turned into a durable workload contract before any sched-ext code is changed. Covers selectors, direct metrics, proxy metrics, guardrails, and saved contract hygiene.

2026-04-231

sched-ext-rollout-safety

DarkHighness/nanoclaw

Use when a sched-ext candidate is about to be activated through the privileged daemon. Covers rollout gates, daemon usage limits, rollback triggers, and how to keep deployment evidence attributable.

2026-04-231

sched-perf-analysis

DarkHighness/nanoclaw

Use when collected scheduler evidence needs to be turned into explicit facts, inferences, unknowns, and candidate design implications. Covers repo helper scripts for uv-managed analysis environments, pandas or polars summaries, and matplotlib plots.

2026-04-231

sched-perf-collection

DarkHighness/nanoclaw

Use when scheduler-related performance evidence has to be collected reproducibly for a workload, target selector, or experiment phase. Covers low-overhead counters first, escalation to traces, and repo scripts that keep capture deterministic without baking a workflow into the host.

2026-04-231

name	ebpf-performance-engineering
description	Use when a task requires writing, loading, or reasoning about eBPF programs for Linux performance analysis. Covers tool selection across bpftrace, BCC, and libbpf CO-RE, plus hook choice, build or load steps, map design, verification, and overhead control. Do not trigger for generic Linux perf analysis that can be handled without custom eBPF work.

eBPF Performance Engineering

When to use

Write or adapt an eBPF probe for performance analysis.
Decide whether bpftrace, BCC, or libbpf CO-RE is the right implementation path.
Load, attach, and verify eBPF programs safely on Linux.

Read before implementing

references/toolchain-selection.md for choosing bpftrace, BCC, or libbpf CO-RE.
references/libbpf-core-workflow.md for the standard compile, skeleton, load, attach, and cleanup flow.

Workflow

Start from the measurement question.
- What event, latency, queue, or stack attribution is missing?
- What is the acceptable overhead?
Choose the right implementation level.
- bpftrace: one-liners and short scripts for quick interactive diagnostics.
- BCC: ready-made tools or Python-driven prototypes.
- libbpf CO-RE: version-portable, reusable probes that belong in a repository or product workflow.
Choose the safest hook.
- Prefer tracepoints or fentry/fexit when available.
- Use kprobe/kretprobe only when stable higher-level hooks do not exist.
- Use uprobes or USDT for user-space behavior.
Keep the kernel-side program minimal.
- Filter early.
- Aggregate in maps when possible.
- Emit only the data needed for the question.
- Avoid high-cardinality keys unless the workload and memory budget justify them.
Load and verify deliberately.
- Confirm privileges, kernel support, BTF availability, and toolchain availability.
- Compare eBPF output with perf, sysstat, or known workload events when possible.
Clean up after the run.
- Detach links, remove pinned objects if used, and note any kernel settings changed for the run.

Engineering rules

Favor narrow probes over broad tracing.
Prefer latency histograms, counters, and sampled attribution to verbose per-event logs.
Measure or estimate overhead when event rates are high.
Document the kernel assumptions and required capabilities.

Output expectations

State why eBPF is needed instead of perf or plain counters.
Name the hook, map or buffer strategy, load path, and validation plan.
If implementing code, include build and run instructions.