When "idle" isn't idle: how a Linux kernel optimization became a QUIC bug
sbulaev
61 points
2 comments
May 12, 2026
Related Discussions
Found 5 related stories in 81.7ms across 8,303 title embeddings via pgvector HNSW
- io_uring, libaio performance across Linux kernels and an unexpected IOMMU trap tanelpoder · 61 pts · March 24, 2026 · 52% similar
- Noq: n0's new QUIC implementation in Rust od0 · 179 pts · March 19, 2026 · 51% similar
- Linux Page Faults, MMAP, and userfaultfd for fast sandbox boot times shayonj · 14 pts · March 12, 2026 · 49% similar
- A tale about fixing eBPF spinlock issues in the Linux kernel y1n0 · 53 pts · March 18, 2026 · 48% similar
- OpenBSD: PF queues break the 4 Gbps barrier defrost · 188 pts · March 19, 2026 · 47% similar
Discussion Highlights (2 comments)
blahgeek
The more precise title should be: How we copied code from Linux kernel without fully understand it and missed its follow-up fixes, now it bites us
neuralkoi
I can see why they rewrote QUIC in Rust and for use in userspace, though going the in-house approach would warrant keeping an eye on the relevant kernel commits like a hawk to avoid missing bug fixes like these. These in-house implementations tend to have less eyeballs than the kernel. I found it interesting that Cloudflare is not yet using BBR. CUBIC's recovery in this day and age, and especially in datacenters with large pipes, seems so slooow to me. Almost two seconds with no loss whatsoever till achieving BDP again and then shooting itself in the foot every time it hits the ceiling. Each one of those losses a retransmission.