A paper on why io_uring workloads are so hard to see into. Submission and completion happen in rings shared with the kernel, so strace catches only the setup call and you are left guessing when something goes wrong. uringscope is a single binary eBPF tool that watches those rings and rebuilds the life of each request from raw kernel events, using CO-RE, BTF probes, and flexible field lookups so one build survives the tracepoint churn across kernel versions. On real NVMe workloads it costs about 0.7 to 9.9 percent of throughput, cheaper than the other tools measured at the same level of detail. The same data feeds a doctor mode that turns raw measurements into named problems with the evidence behind them, aimed at someone chasing a tail latency bug rather than browsing histograms.
A paper from Amazon engineers on how Aurora DSQL works inside. DSQL is a serverless SQL database that runs active active across regions, so any region can take reads and writes at once. The design splits the two apart: reads use multiversion concurrency control with precise timestamps and never coordinate with other nodes, while writes use optimistic concurrency control and coordinate only at commit time, through components called adjudicators and a replication layer called the Journal. Query processors run in small Firecracker microVMs and keep no local state, which lets compute, storage, and coordination scale on their own, from idle up to millions of transactions per second. The paper shows how all of this keeps full ACID transactions even when an availability zone or a whole region fails.
Paul McKenney's paper on why memory barriers exist at all, built from the hardware up. It starts with how a CPU cache is laid out, then how the MESI protocol keeps caches agreeing on the value of each location, then how store buffers and invalidate queues quietly break that agreement in exchange for speed. Once you see those two queues, read and write barriers stop looking arbitrary and start looking like the obvious fix.
A USENIX ATC paper that looks back at how DynamoDB grew from the original Dynamo design into a managed service. It shares what the team learned from running the system at a very large scale and shows how distributed storage works in production, not just in theory.