Reworking 30 lines of Linux code could cut power use by up to 30 percent

Original Article ↗ Hacker News Discussion ↗

Age and Reposting of the News

  • Debate over whether a 3‑month‑old kernel change is “stale” or still useful to feature.
  • Some argue it’s been reposted too often and kernel devs already moved on; others say most users don’t track mainline closely and only see changes once distros ship them.
  • Broader preference tension: “only new” vs “filtered by time” news, with some preferring older, vetted items over fresh hype.

What the Patch Actually Does

  • Change targets Linux’s busy polling networking path, via epoll busy poll and a specific ioctl.
  • It allows the kernel to suspend NIC IRQs while user space busy‑polls, then back off when traffic is low, cutting wasted CPU cycles.
  • Only applies if applications explicitly opt into epoll busy polling; default NAPI behavior is unaffected.
  • The “up to 30%” number is from benchmarks on network‑heavy apps (e.g., memcached); it’s savings on the networking/communication part, not whole‑system power.

Scope and Applicability

  • Many commenters stress this is mainly relevant for data‑center‑style, latency‑sensitive workloads that already use busy polling.
  • Typical desktops, laptops, and home routers usually won’t see a benefit; many commercial routers offload most traffic to hardware anyway.
  • Some embedded and custom Linux routing/NAS setups might benefit, but only if they use the specialized busy‑poll APIs.
  • Others note that many high‑performance data‑center stacks bypass the kernel entirely (DPDK, XDP, userspace stacks), so this patch won’t help those.

Linux, Android, and Install Base

  • Discussion over what “Linux” refers to: kernel vs “Linux distributions” vs Android.
  • Several point out that most Linux kernels in the world likely run on Android devices or embedded/IoT, not traditional servers or desktops.

Performance, Efficiency, and Incentives

  • Strong agreement that energy‑efficient code matters, especially at hyperscale and in HPC.
  • Contrast between “premature optimization” in app code and justified low‑level optimization in the kernel.
  • Some call for “green X‑prize”-style incentives; others argue hyperscalers already have strong financial motivation but may still underinvest due to misaligned incentives.
  • Side thread: profiling vs using LLMs to find inefficiencies—profilers are seen as the correct tool.