When a kernel component like a storage driver misbehaves in production, developers face a difficult choice. They either have too little information to solve the bug or they enable slow console-level debug logs that ruin performance. This talk introduces a per-component binary logging mechanism designed to support verbose logging in production with negligible run-time cost.

We achieve this efficiency by moving the heavy lifting to build time. using preprocessor macros, we emit parameter serialization stubs and save location-specific formats in a separate side table. At run time, the hot path only records a location ID, a timestamp, and the raw parameters. No format expansion occurs until the logs are read. We support high concurrency using a mostly lock-free multi-level allocator that allows dozens of CPUs to write simultaneously.

We also introduce a significant architectural change by adding a single TLS pointer to struct task_struct. This tags each thread with a private logging buffer. If a thread stalls or deadlocks, the tag remains attached to the buffer. This allows post-mortem analysis to reveal the exact context-specific history of that thread.

Unlike ftrace_printk which dumps everything into a single global ring, our logger maintains one ring per component context. This allows you to capture exactly the data you need for a specific file system or operation. The memory footprint is minimal. Each record is only eight bytes. This saves 16 bytes per entry compared to the standard bprint_entry. This efficiency reduces memory accesses and facilitates a truly production-ready binary logging infrastructure.

We can finally keep verbose logging active at all times. This ensures that when a crash or deadlock occurs, the high-fidelity history needed to solve it is already waiting in memory.