61–70 of 123 posts
This is really cool. As a high-performance computing professional, I've often wondered how much energy is wasted due to inefficient code and how much that is a problem as planetary compute scales up. For me, it feels like a moral imperative to make my code as efficient as possible, especially when a job will take months to run on hundreds of CPU.
Instead, they use DPDK, XDP, or userspace stacks like Onload or VMA—often with SmartNICs doing hardware offload. In those cases, this patch wouldn’t apply, since packet processing happens entirely outside the kernel.
That doesn’t mean the patch isn’t valuable—it clearly helps in setups where the kernel is in the datapath (e.g., CDNs, ingress nodes, VMs, embedded Linux systems). But it probably won’t move the needle for workloads that already bypass the kernel for performance or latency reasons. So the 30% power reduction headline is likely very context-dependent.
When a machine is large enough with enough tenants, there should be enough ambient junk going on to poll on 1 or a few cores and still be optimized for power. This is the tradeoff described in the 2019 "SNAP" paper from Google, in the section about the compacting engine. The "up to 30%" figure is operative when you have a near-idle application that's busy polling, which is already dumb. There are several ways to save…
That was my first thought, but it sounds like the OS kernel, not the application, has control over the polling behavior, right?
For a more detailed look at this change: https://lwn.net/Articles/1008399/
The power efficiency seems to be limited to "network applications using epoll".
The 30% the article talks about seems to be benchmarked on memcached, and here is the ~30 lines diff they're probably talking about: https://raw.githubusercontent.com/martinkarsten/irqsuspend/m...
Linux added a busy polling feature for high performance networking. Most Linux software does not use it, but software used in datacenters (e.g. by CDNs) that does use it makes the system very energy inefficient when things are not busy. This patch gives the the kernel the ability to turn that off when not busy to regain energy efficiency until things become busy again. The article name is somewhat misleading, since i…
It’s a lot more nuanced than that. Being in a data center doesn’t imply heavy network utilization. The caveat is clearly outlined in the article being workload based not deployment based. If you have a home machine doing network routing it would absolutely benefit from this. In fact I would say probably the vast majority of Linux installs are home network devices, just people don’t know it. Embedded Linux machines do…
It most likely won't. This patch set only affects applications that enable epoll busy poll using the EPIOCSPARAMS ioctl. It's a very specialized option that's not commonly used by applications. Furthermore, network routing in Linux happens in the kernel, not in user space, so this patch set doesn't apply to it at all.
Earlier quoted context omitted.
My experience with HPC is only tangential to being a sysadmin for data taking and cluster management for a high energy physics project; I am interested on your thoughts about using generative AI to search out for potentially power inefficient code paths in codebases for potential improvement.
Don't send an LLM to do a profiler's job.
This is really cool. As a high-performance computing professional, I've often wondered how much energy is wasted due to inefficient code and how much that is a problem as planetary compute scales up. For me, it feels like a moral imperative to make my code as efficient as possible, especially when a job will take months to run on hundreds of CPU.
Year ago, I posted here that there should be some sort of ongoing Green X-Prize for this style of Linux kernel optimization. It's still crazy to me that this doesn't exist.
Earlier quoted context omitted.
Absolutely. It is unfortunate that many software engineers continue to dismiss this as "premature optimization". But as soon as I see resources or server costs gradually rising every month (even on idle usage) costing into the tens of thousands which is a common occurrence as the system scale, then it becomes unacceptable to ignore.
When you achieve expertise you know when to break the rules. Until then it is wise to avoid premature optimization. In many cases understandable code is far more important. I was working with a peer on a click handler for a web button. The code ran in 5-10ms. You have nearly 200ms budget before a user notices sluggishness. My peer "optimized" the 10ms click handler to the point of absolute illegibility. It was doubtf…
Earlier quoted context omitted.
Year ago, I posted here that there should be some sort of ongoing Green X-Prize for this style of Linux kernel optimization. It's still crazy to me that this doesn't exist.
I would hope that the hyperscalers have sufficient economic incentive to optimize this without an X-prize.
Also, would you share all new found efficiencies with your competitors?
This is really cool. As a high-performance computing professional, I've often wondered how much energy is wasted due to inefficient code and how much that is a problem as planetary compute scales up. For me, it feels like a moral imperative to make my code as efficient as possible, especially when a job will take months to run on hundreds of CPU.
Absolutely. It is unfortunate that many software engineers continue to dismiss this as "premature optimization". But as soon as I see resources or server costs gradually rising every month (even on idle usage) costing into the tens of thousands which is a common occurrence as the system scale, then it becomes unacceptable to ignore.