Login

u/Icy_Ad_1327

r/DistroHopping r/eBPF r/lowlevel r/developersIndia r/linuxquestions
I built a Linux observability tool that correlates 11 layers of the kernel in real time from procfs to eBPF rendered entirely in x86-64 assembly.
▲ 22 r/eBPF+1 crossposts

I built a Linux observability tool that correlates 11 layers of the kernel in real time from procfs to eBPF rendered entirely in x86-64 assembly.

Most Linux debugging tools answer one question well.

  • top tells you who's using the CPU.
  • strace tells you which syscalls are happening.
  • perf tells you what the CPU is doing.
  • vmstat tells you about memory.

But when something weird happens, I always found myself jumping between half a dozen tools and trying to correlate timestamps manually.

So I started building ASCENT.

The idea is to visualize the entire stack simultaneously instead of looking at one layer at a time.

Current implementation includes 9 live layers:

  • System metrics (/proc)
  • Process activity
  • Syscall statistics
  • Kernel datapath (vfs_read, tcp_sendmsg, etc.)
  • Hardware PMU counters
  • Scheduler dynamics
  • Memory management
  • Lock contention
  • IRQ / softirq / workqueue causality

Everything is streamed into a single terminal dashboard.

A few things that made this project fun:

  • Dashboard written in pure x86-64 NASM assembly
  • No libc
  • No runtime
  • No allocator
  • Uses ANSI escape sequences for rendering
  • eBPF CO-RE sensors
  • PMU counters through perf_event_open()
  • Fixed 60-byte binary event protocol over a FIFO between the loader and the renderer

The goal isn't to replace tools like perf or bpftrace. It's to answer a different question:

>

There are still a lot of things left to build (Intel PT, KVM tracing, AI-based correlation, etc.), but the core pipeline is working.

I'd love feedback from people who work with Linux internals or eBPF.

GitHub: https://github.com/Kritagya123611/Ascent

u/Icy_Ad_1327 — 8 days ago
▲ 1 r/DistroHopping

Building an eBPF-driven desktop distro that actively fights lag (Looking for architectural feedback)

Hey everyone,

I’m mapping out the architecture for a custom Linux distro built from scratch. The goal: Make a 5-year-old laptop feel incredibly fast by bringing iOS/Android-style aggressive background app suspension to the Linux desktop.

**The Architecture:** Standard Linux schedulers try to be fair. This distro will be intentionally *unfair*.

  1. **Telemetry:** Using eBPF (and potentially the new `sched_ext` BPF scheduler class) to monitor CPU wakeups, heavy syscalls, and page faults with near-zero overhead.
  2. **The Brain:** A fast userspace daemon (Go/Rust) polling the eBPF maps.
  3. **Enforcement:** If the active workspace starts lagging, the daemon dynamically throttles or freezes (`cgroup` freezer) background offenders to protect UI responsiveness.

**My concerns before I start coding:**

* **Overhead:** Attaching BPF programs to every context switch on older hardware might cause the exact lag I'm trying to fix. * **Legacy Apps:** Traditional X11/Wayland desktop apps aren't designed to be forcefully suspended. I'm anticipating dropped sockets and massive crashes upon waking them up.

**Questions:**

  1. Has anyone experimented with using eBPF for *active* desktop resource management (freezing/throttling) rather than just observability?
  2. How destructive is it to aggressively freeze/resume standard desktop apps via cgroups in practice?
  3. Is this basically just `systemd-oomd`, but utilizing freezing instead of `SIGKILL`?

Let me know why this will fail. Thanks!

reddit.com
u/Icy_Ad_1327 — 25 days ago
▲ 3 r/linuxquestions+1 crossposts

Building an eBPF-driven linux distro that actively fights lag (Roast my architecture)

Hey everyone,

I’m mapping out the architecture for a custom Linux distro built from scratch. The goal: Make a 5-year-old laptop feel incredibly fast by bringing iOS/Android-style aggressive background app suspension to the Linux desktop.

The Architecture: Standard Linux schedulers try to be fair. This distro will be intentionally unfair.

  1. Telemetry: Using eBPF (and potentially the new sched_ext BPF scheduler class) to monitor CPU wakeups, heavy syscalls, and page faults with near-zero overhead.
  2. The Brain: A fast userspace daemon (Go/Rust) polling the eBPF maps.
  3. Enforcement: If the active workspace starts lagging, the daemon dynamically throttles or freezes (cgroup freezer) background offenders to protect UI responsiveness.

My concerns before I start coding:

  • Overhead: Attaching BPF programs to every context switch on older hardware might cause the exact lag I'm trying to fix.
  • Legacy Apps: Traditional X11/Wayland desktop apps aren't designed to be forcefully suspended. I'm anticipating dropped sockets and massive crashes upon waking them up.

Questions:

  1. Has anyone experimented with using eBPF for active desktop resource management (freezing/throttling) rather than just observability?
  2. How destructive is it to aggressively freeze/resume standard desktop apps via cgroups in practice?
  3. Is this basically just systemd-oomd, but utilizing freezing instead of SIGKILL?

Let me know why this will fail. Thanks!

reddit.com
u/Icy_Ad_1327 — 25 days ago