BPF OOM Kernel Patches Deep Dive: Custom OOM Policies with eBPF

5 min read
The previous articles showed how to use eBPF to observe OOM events. But we could only watch, not intervene. The kernel’s OOM Killer decides who lives and dies based on the oom_badness() algorithm, with no user control. In 2025, Google engineer Roman Gushchin proposed the BPF OOM kernel patch series, aiming to let eBPF programs fully take over OOM handling policy. This is the biggest change to Linux memory management’s OOM subsystem in nearly two decades.
EBPF Linux OOM Kernel Kfunc PSI Roman Gushchin
Continue reading →

Advanced eBPF Memory Observability: Container Tracing and Rust Aya

7 min read
The first two articles covered eBPF fundamentals and OOM Killer event tracing. This article goes deeper: container-level OOM pinpointing, real-time memory allocation rate tracking, and implementing the same functionality with the Rust Aya framework. Container-Level OOM Pinpointing In Kubernetes, “a Pod OOM’d” is actually a vague statement. A Pod consists of multiple containers, each belonging to different cgroups. eBPF can drill through this layer and precisely identify which container and which process caused the OOM.
EBPF Rust Aya Memory Management OOM Cgroup Linux
Continue reading →

Building an OOM Killer Event Tracer with eBPF + Go

6 min read
bpftrace is great for quick probing and ad-hoc debugging. For production-grade monitoring tools, you need full eBPF programs. The architecture splits into two layers: Kernel side: eBPF program written in C, attached to hook points, collecting event data User side: loader written in Go (or Rust / libbpf C), loading the eBPF program and reading events Architecture mermaid flowchart LR classDef kern fill:#E3F2FD,stroke:#1565C0,color:#1565C0 classDef user fill:#FFF3E0,stroke:#E65100,color:#BF360C classDef data fill:#E8F5E9,stroke:#2E7D32,color:#1B5E20 subgraph kernel["Kernel Space"] hook@{ shape: rounded, label: "oom_kill_process (kprobe)" } ebpf@{ shape: proc, label: "eBPF Program\nEvent Collection" } ring@{ shape: cyl, label: "Ring Buffer" } end subgraph userspace["User Space (Go)"] loader@{ shape: notch-rect, label: "bpf2go Loader" } reader@{ shape: proc, label: "RingBuf Reader\nEvent Parsing" } end hook --> ebpf --> ring ring --> reader loader -.-> ebpf class hook,ebpf,ring kern class loader,reader user eBPF Kernel Program (C) Name the C file oom_kprobe.bpf.c — the bpf suffix is a cilium/ebpf convention for bpf2go code generation:
EBPF Go Cilium Linux OOM Memory Management
Continue reading →

eBPF Observability: Getting Started with OOM Killer Monitoring

8 min read
eBPF (Extended Berkeley Packet Filter) started as a network packet filtering tool, but over nearly a decade it has evolved into the most powerful observability framework in the Linux kernel. It allows you to safely inject and execute custom programs without modifying kernel source code or loading kernel modules. This article kicks off the series, using OOM (Out-of-Memory) monitoring as a concrete entry point to learn the core eBPF concepts and toolchain.
EBPF Linux OOM Memory Management Bpftrace
Continue reading →

Loop Engineering: Designing AI's Self-Driving Systems

2 min read
What Is Loop Engineering? Definition (Addy Osmani, June 2026): Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead. The loop is a recursive goal where you define a purpose and the AI iterates until complete. Simply put: Loop Engineering = letting the system start its own workflows. Example: Traditional way: You discover bug → You say “fix this bug” → AI fixes it Loop Engineering: System automatically discovers bug → System says “fix this bug” → AI fixes it Origins The evolution of this concept:
AI Engineering Paradigm Evolution Loop Engineering Agent
Continue reading →

MiBeeNvr v0.6.0: Timelapse + Transcoding UI + ONVIF Enhancements + Documentation Restructure

11 min read
After running continuous recording for a few weeks, storage became the first bottleneck. A single 1080p camera writes tens of GB per day — with a 30-day retention policy, a 1TB drive is mostly consumed. Many community members reported the same issue, and during discussions, the ideas of timelapse and transcoding storage gained the most traction: most of the time the scene is static, and compressing it with timelapse requires only 5% of the space for the same duration.
NVR Go Timelapse Transcoding ONVIF H.265 LL-HLS Open Source
Continue reading →

MiBeeNvr v0.6.0's Test Machines: Three Camera Projects Updated in Sync

6 min read
The concurrently released MiBeeNvr v0.6.0 brought major features like timelapse, video transcoding, and ONVIF enhancements. Unit tests alone are far from enough — the full workflow must be tested against real camera hardware. To provide reliable test machines for this release, three camera projects were updated on the same day, June 5th — both to supply testing environments for the NVR and to solve some typical embedded development engineering problems along the way.
ESP32-S3 Raspberry Pi Camera Testing NVR Open Source PSRAM WiFi
Continue reading →

MiBeeNvr v0.5.0: Full ONVIF Protocol Support + Hardware Transcoding + rpi-cam Co-development

10 min read
Less than a week after v0.4.0, another 31 commits were pushed. v0.5.0 is a feature-dense release: full ONVIF protocol support (covering all five major services: Device/Media/PTZ/Imaging/Event), hardware transcoding (H.265 → H.264), and recorder reconnection optimizations. 127 files changed, +24,509 / -730 lines. See the full changelog at GitHub Release Notes. If you haven’t seen the previous versions, check out MiBeeNvr Introduction and v0.4.0 Technical Post. Full ONVIF Protocol Support v0.4.0 already had ONVIF device discovery and stream URL retrieval, but that was just the tip of the ONVIF iceberg. v0.5.0 completes the core services of ONVIF Profile S:
NVR Go ONVIF PTZ Transcoding Raspberry Pi Rpi-Cam Open Source
Continue reading →

From Harness to Loop: If You Have to Start It Every Time, It's Not Autonomous

3 min read
Scene: The System Is Reliable, But Humans Are Still the Bottleneck Imagine a scenario where you have a perfect Harness system. AI can: Analyze requirements and write code Run tests and validate outputs Fix discovered bugs Optimize performance and code quality Every step works well—reliable, predictable, controllable. But whenever a bug is found, you must say “fix this bug.” Then another bug appears, and you say “fix this too.” Then comes a new feature request, and you say “implement this feature.”
AI Engineering Paradigm Evolution Loop Engineering
Continue reading →

YOLO Rust Deployment Guide

6 min read
Chapter 9: Complete YOLO Tutorial with Rust With its three core characteristics of memory safety, zero-cost abstractions, and extreme performance, Rust has become the ultimate choice for production-grade YOLO deployment. In edge computing and high-concurrency scenarios, Rust’s performance advantages are particularly significant. YOLO-related Libraries in Rust Ecosystem Library Name Crates.io Maintenance Status Use Cases Recommendation Index ort (onnxruntime-rs) v2.0.0 Super Active Official ONNX binding, full platform support ⭐⭐⭐⭐⭐ ultralytics-inference v0.0.11 Official Maintenance Official Ultralytics Rust library ⭐⭐⭐⭐⭐ tract v0.21.0 Active Pure Rust inference engine, no external dependencies ⭐⭐⭐⭐ opencv-rust v0.94.0 Active OpenCV binding, DNN + image processing ⭐⭐⭐⭐ tch-rs v0.15.0 Active LibTorch binding, PyTorch models ⭐⭐⭐ candle v0.6.0 Super Active HuggingFace pure Rust ML framework ⭐⭐⭐⭐ Core Features Comparison:
YOLO Rust ONNX Runtime Model Deployment Edge Computing
Continue reading →