From a0b170f1ca08019e95f6a6dcd6073a06c9ac7bb2 Mon Sep 17 00:00:00 2001 From: TickTockBent Date: Wed, 18 Mar 2026 07:47:55 -0400 Subject: [PATCH] fix: use bpf_get_smp_processor_id for accurate cpu_id in events get_cpu_id() was stubbed to always return 0 because aya-ebpf didn't appear to expose bpf_get_smp_processor_id. Turns out it does, via the re-exported bindings (helper #8), it's just #[doc(hidden)] so it doesn't show up in the generated docs. Every exported trace event was reporting cpu_id: 0 regardless of which core the sample was actually taken on. The TUI doesn't render per-CPU data so nobody noticed, but the Chrome Trace JSON was silently wrong. // ticktockbent --- hud-ebpf/src/main.rs | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/hud-ebpf/src/main.rs b/hud-ebpf/src/main.rs index 8aefde5..e412995 100644 --- a/hud-ebpf/src/main.rs +++ b/hud-ebpf/src/main.rs @@ -28,7 +28,7 @@ #![allow(unused_unsafe)] use aya_ebpf::{ - helpers::{bpf_get_current_pid_tgid, bpf_ktime_get_ns}, + helpers::{bpf_get_current_pid_tgid, bpf_get_smp_processor_id, bpf_ktime_get_ns}, macros::{map, perf_event, tracepoint, uprobe}, maps::{HashMap, RingBuf, StackTrace}, programs::{PerfEventContext, ProbeContext, TracePointContext}, @@ -301,11 +301,9 @@ fn get_worker_id(tid: u32) -> u32 { unsafe { TOKIO_WORKER_THREADS.get(&tid).map(|info| info.worker_id).unwrap_or(u32::MAX) } } -// Helper: Get CPU ID (using aya's helper when available) +// Helper: Get CPU ID from the BPF helper fn get_cpu_id() -> u32 { - // aya-ebpf doesn't expose bpf_get_smp_processor_id directly yet - // For now, return 0 (we can add this later with raw bpf call) - 0 + unsafe { bpf_get_smp_processor_id() } } /// CPU Sampling Profiler - Captures stack traces via perf_event