[HN Gopher] Reworking 30 lines of Linux code could cut power use...
___________________________________________________________________
Reworking 30 lines of Linux code could cut power use by up to 30
percent
Author : gslin
Score : 245 points
Date : 2025-04-21 07:34 UTC (15 hours ago)
(HTM) web link (spectrum.ieee.org)
(TXT) w3m dump (spectrum.ieee.org)
| d3Xt3r wrote:
| > _The code has been implemented as part of the Linux kernel
| release version 6.13 in January._
|
| This is basically 3 month old news now.
| ryao wrote:
| If you read the original commit comment, userspace software
| needs to opt into this:
|
| https://web.git.kernel.org/pub/scm/linux/kernel/git/torvalds...
|
| If it is not reported for people to know about it, this will do
| nothing.
|
| That said, the opt-in here is only relevant when software has
| already opted into busy polling, so it likely does not apply to
| software used outside of datacenters.
| Almondsetat wrote:
| Did you know about this before reading the article?
| d3Xt3r wrote:
| Yes, it was posted before over here and other news sites.
| I've seen it reposted several times over the past three
| months.
| TheRealPomax wrote:
| So, new enough that millions of people never heard about it. I
| can see why it made the front page.
| matkoniecz wrote:
| What is wrong with 3 month old news? I in fact prefer ones that
| are not repeated based only on basis being new and much more
| likely to be confused/misleading/hoax/lie/not actually
| interesting.
|
| Similarly, I prefer old books, old computer games, old movies
| (or at least not ones currently being hot/viral/advertised),
| this allows a lot of trash to self-filter out. Including trash
| being breathlessly promoted and consumed.
| d3Xt3r wrote:
| What's wrong with it is the fact that it was already posted
| before over here and other news sites. I've seen it reposted
| several times over the past three months and I'm tired of
| seeing this.
|
| 6.13 is old news now, we're already on 6.14, and even 6.15
| isn't far from release (we're already at rc3).
| throw-qqqqq wrote:
| Well, I run Linux on both my laptops and desktops, consider
| myself an enthusiast etc., but I don't track the development of
| the mainline Linux kernel closely enough to know what goes on
| there in the past three months.
|
| I may notice changes when they get adopted by upstream
| maintainers of my distro, but that usually takes time..
| d3Xt3r wrote:
| That doesn't make it okay to repost stale news. Would you be
| okay if I went to say phoronix.com, started picking other
| notable 3-month old Linux kernel articles and repost them
| here one by one? Heck, why limit myself just to the Linux
| kernel, why don't I just start reposting all the top
| headlines in the past few months, because surely not everyone
| is up-to-date on all the developments right?
| tverbeure wrote:
| I'm one of the lucky 10,000.
| infogulch wrote:
| Wow busy waiting is more resource intensive than I realized.
| ryao wrote:
| 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 it makes it sound
| like this would also apply to desktop workloads. The article says
| it is for datacenters and that is true, but it would have been
| better had the title ended with the words "in datacenters" to
| avoid confusion.
| jes5199 wrote:
| you don't have to say "in datacenters" when talking about
| linux, that is the obvious context in the vast majority of
| cases
| ptero wrote:
| IME majority of linux systems are laptops and desktops.
| jolmg wrote:
| Without looking at stats, I would think android phones.
| billy99k wrote:
| Android isn't Linux. While Android uses the Linux kernel,
| it's not a standard Linux distribution. It has its own
| user space and libraries, making it a distinct operating
| system.
| hasperdi wrote:
| Linux is the kernel. Android uses a forked version of the
| mainline Linux
| murderfs wrote:
| Everyone uses a forked version of the mainline Linux.
| kbolino wrote:
| This means it's not GNU/Linux, but that's not the only
| flavor of Linux. Alpine uses busybox and musl instead of
| GNU userland and glibc, but few would say it's not a
| Linux distribution.
| homarp wrote:
| at least inside docker or wsl
| jonhohle wrote:
| Docker wouldn't be affected by this, the network stack is
| lower. WSL would, however.
| teeray wrote:
| IoT devices would like a word
| panzi wrote:
| I'm reading this on an Android phone. The phone OS that has
| over 70% market share.
| matkoniecz wrote:
| Why you think so? Especially for HN readers decent chunk is
| using Linux.
|
| (I typed this on Linux PC).
| devsda wrote:
| Agree. On reading the headline, I was hoping it would
| extend my laptop battery life.
| tisdadd wrote:
| Same here, I have used Linux as my main for a long time.
| Though, I would imagine that data centers do have more
| instances than the desktops and laptops around the world
| combined.
| helij wrote:
| And another one here!
| ajross wrote:
| This is a naming mistake. You're taking "Linux" in the sense
| of "Linux Distribution", where the various competitors have
| seen most of their success in the datacenter.
|
| This is specifically a change to the _Linux kernel_ , which
| is much, much more broadly successful.
| Tireings wrote:
| Indeed he has to.
| fnordpiglet wrote:
| 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
| doing network routing or switching or IPS or NAS or whatever
| would benefit a lot from this. "Energy savings" can be seen as
| a green washing statement but on embedded budgets it's a
| primary requirement.
| taeric wrote:
| I was curious how much this would be applicable to home
| routers.
|
| I confess I'm dubious on major savings for most home users,
| though? At least, at an absolute level. 30% of less than five
| percent is still not that big of a deal. No reason not to do
| it, but don't expect to really see the results there.
| fnordpiglet wrote:
| For embedded it's not about saving cost it's about saving
| limited on board power. The lower the power demand of the
| device, the smaller and the more you can dedicate to other
| things.
| taeric wrote:
| Again, no reason not to do this change. I'm not clear it
| helps in this case, though? The savings is in low use
| time. During high use time, it is the same, right?
| tuetuopay wrote:
| Practically none of it would be applicable (if using a
| commercial router). They all use hardware offloading, and
| traffic seldom touches the CPU. Only "logical" tasks are
| raised to the CPU, like ARP resolution and the likes
| (what's called "trap to cpu").
|
| If you're doing custom routing with a NUC or a basic Linux
| box, however, this would gain massive power savings because
| that box pretty much only does networking.
| ori_b wrote:
| Only if you're using busy polling. Very little software
| uses it, because it's only a good fit if you think
| pegging a CPU to reduce latency responding to packets is
| a good trade.
| tuetuopay wrote:
| Yup, you're right. I always forget this patch only
| applies to opted-in polling and not automatic polling for
| interrupt moderation.
| jeffbee wrote:
| What home router would be busy polling?
| sandworm101 wrote:
| Someone who decided to turn their old PC into a router
| because a youtube video daid "recycling" an old PC is more
| green despite the massive power suck.
| jeffbee wrote:
| I feel like I'm repeating myself, but there are no people
| out there running Linux and unintentionally busy polling
| their network interface. This is something almost nobody
| does.
| Denvercoder9 wrote:
| > If you have a home machine doing network routing it would
| absolutely benefit from this.
|
| 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.
| p_l wrote:
| NAPI is not busy poll, though, and the way the article is
| worded suggests it's about NAPI.
|
| Now, NAPI already was supposed to have some adaptiveness
| involved, so I guess it's possibly a matter of optimizing
| it.
|
| But my system is compiling for now so will look at article
| more in depth later :V
| wkat4242 wrote:
| There should have been an off switch from the beginning
| though IMO, though perhaps there already is? But the number
| of corporates messing with the kernel for their own purposes
| greatly outnumbers the number of independent developers. That
| gives big tech a big influence. And the Linux Foundation is
| there to cement that influence.
|
| I much prefer grassroots projects. Made by and for people
| like me <3 That's why I moved to BSD (well there were other
| reasons too of course)
| varjag wrote:
| Uh Linux is a grassroots project, quite unlike Berkley
| Software Distribution.
|
| Also no you are entirely unaffected by this unless you use
| a very specific and uncommon syscall.
| nottorp wrote:
| So it's not even on by default, it needs to be turned on
| explicitly?
| eichin wrote:
| heh, will this become the equivalent of "in mice" for bio
| papers?
| queuebert wrote:
| 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.
| toomuchtodo wrote:
| 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.
| jeffbee wrote:
| Don't send an LLM to do a profiler's job.
| queuebert wrote:
| I agree with this.
|
| For the completely uninitiated, taking the most critical
| code paths uncovered via profiling and asking an LLM to
| rewrite it to be more efficient might give an average user
| some help in optimization. If your code takes more than a
| few minutes to run, you definitely should invest in
| learning how to profile, common optimizations, hardware
| latencies and bandwidths, etc.
|
| With most everything I use at the consumer level these
| days, you can just feel the excessive memory allocations
| and network latency oozing out of it, signaling the
| inexperience or lack of effort of the developers.
| rvz wrote:
| 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.
| samspot wrote:
| 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 doubtful the new implementation was faster.
| adrianN wrote:
| DBs can compile and run complex queries in that time
| budget. What did the click handler do?
| conductr wrote:
| I'd think anything as old and widely used as Linux would not
| be seen as premature, with All optimizations welcome
| consumer451 wrote:
| 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.
| adrianN wrote:
| I would hope that the hyperscalers have sufficient economic
| incentive to optimize this without an X-prize.
| consumer451 wrote:
| One would hope, but when I last gave this some thought...
| If you are in the C-suite, and could deploy your best devs
| to _maybe_ save some unknown % on energy costs, or have
| them work on a well-defined new feature that grows your ARR
| 5% next year, which would you do?
|
| Also, would you share all new found efficiencies with your
| competitors?
| jeffbee wrote:
| At a large business the 1% cost savings is going to be a
| lot easier to find than the 5% revenue growth.
| timewizard wrote:
| > 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.
|
| I personally believe the majority is wasted. Any code that runs
| in an interpreted language, JIT/AOT or not, is at a significant
| disadvantage. On performance measurements it's as bad as 2x to
| 60x worse than the performance of the equivalent optimized
| compiled code.
|
| > it feels like a moral imperative to make my code as efficient
| as possible
|
| Although we're still talking about fractions of a Watt of power
| here.
|
| > especially when a job will take months to run on hundreds of
| CPU.
|
| To the extent that I would say _only_ in these cases are the
| optimizations even worth considering.
| myself248 wrote:
| Meanwhile I'm running four Electron apps just to act like
| different shitty IRCs.
| corbet wrote:
| For a more detailed look at this change:
| https://lwn.net/Articles/1008399/
| pouulet wrote:
| And for even more details, you can look at the relevant patch:
| https://lwn.net/ml/all/20241021015311.95468-1-jdamato@fastly...
|
| 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...
| mintflow wrote:
| Oh, as a guy which was using DPDK like technology that do busy-
| poll and bypass kernel to process network packets, I must say may
| be much power have be wasted...
| nly wrote:
| Standard practice in all trading applications is to busy poll
| the NIC using a kernel bypass technology.
|
| Typically saves 2-3 microseconds going through the kernel
| network stack.
| jeffbee wrote:
| 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 energy in that case.
| danans wrote:
| > The "up to 30%" figure is operative when you have a near-idle
| application that's busy polling, which is already dumb.
|
| That was my first thought, but it sounds like the OS kernel,
| not the application, has control over the polling behavior,
| right?
| wrsh07 wrote:
| The flip side of this is meta having a hack that keeps their GPUs
| busy so that the power draw is more stable during llm training
| (eg don't want a huge power drop when synchronizing batches)
| jack_riminton wrote:
| I thought of this too. Iirc it was bigger problem because
| surging spikes in power and cooling were harder and more costly
| to account for.
|
| I'm not au fait with network data centres though, how similar
| are they in terms of their demands?
| Scipio_Afri wrote:
| Have a link to an article talking about them doing this?
| endorphine wrote:
| Off topic: glad to read about Joe Damato again -- such a blast
| from the past. I haven't read anything from him since I first
| read James Gollick posts about on tcmalloc and then learning
| about packagecloud.io which eventually led me to Joe's amazing
| posts.
| rvz wrote:
| > When I grew up in computer science in the 90s, everybody was
| concerned about efficiency..."Somehow in the last 20 years, this
| has gotten lost. Everybody's completely gung-ho about performance
| without any regard for efficiency or resource consumption. I
| think it's time to pivot, where we can find ways to make things a
| little more efficient.
|
| This is the sort of performance efficiencies I want to keep
| seeing on this site, from those who are distinguished experts and
| contributed to critical systems such as the Linux kernel.
|
| Unfortunately, in the last 10-15 years we are seeing the worst
| technologies being paraded due to a cargo-cultish behaviour. From
| asking candidates to implement the most efficient solution to a
| problem in interviews but then also choosing the most extremely
| inefficient technologies to solve certain problems because so-
| called software shops are racing for that VC money. Money that
| goes to hundreds of k8s instances on many over-provisioned
| servers instead of a few.
|
| Performance efficiency _critically_ matters, and it is the
| difference between having enough runway for a sustainable
| business vs having none at all.
|
| And nope. AI Agents / Vibe coders could not have come up with a
| more correct solution in the article.
| linsomniac wrote:
| Does this mean that "adaptive interrupt mitigation" is no longer
| a thing in the kernel? I haven't really messed with it in ~15+
| years, but it used to be that the kernel would adapt, if network
| rate was low it would use interrupts, but then above a certain
| point it would switch to turning off interrupts and using polling
| instead.
|
| The issue I was trying to resolve was sudden, dramatic changes in
| traffic. Think: a loop being introduced in the switching, and the
| associated packet storm. In that case, interrupts could start
| coming in so fast that the system couldn't get enough non-
| interrupted time to disable the interrupts, UNLESS you have more
| CPUs than busy networking interfaces. So my solution then was to
| make sure that the Linux routers had more cores than network
| interfaces.
| jeffbee wrote:
| Adaptive IRQ moderation is a hardware feature.
| https://edc.intel.com/content/www/us/en/design/products/ethe...
| didgetmaster wrote:
| This brings back memories.
|
| https://didgets.substack.com/p/finding-and-fixing-a-billion-...
| secondcoming wrote:
| I thought that Intel added the 'pause' instruction to make busy
| spinning more power friendly
| jeffbee wrote:
| x86 has always had PAUSE, what they did is they made the PAUSE
| _way longer_ in Skylake-X which threw everyone off guard. But
| yeah, x86 ISA extensions cover this ground very well. Atom, the
| low-power server line, introduced UMWAIT and TPAUSE that enable
| cores to briefly enter a power-saving active state while
| waiting for something to happen. These instructions later came
| to mainstream Core and Xeon CPUs because Intel made those
| frankenchips with Atoms and Cores together.
| Jeaye wrote:
| Niiice. What if we reworked 100 lines?
| stavros wrote:
| 20%.
| teddyh wrote:
| _A manager went to the master programmer and showed him the
| requirements document for a new application. The manager asked
| the master: "How long will it take to design this system if I
| assign five programmers to it?"_
|
| _"It will take one year," said the master promptly._
|
| _"But we need this system immediately or even sooner! How long
| will it take if I assign ten programmers to it?"_
|
| _The master programmer frowned. "In that case, it will take
| two years."_
|
| _"And what if I assign a hundred programmers to it?"_
|
| _The master programmer shrugged. "Then the design will never
| be completed," he said._
|
| -- Chapter 3.4 of _The Tao of Programming_ , by Geoffrey James
| (1987)
| mrbluecoat wrote:
| Noob question: how do you enable this power saving feature? Is it
| just upgrading to the latest kernel?
| hwpythonner wrote:
| One thing I didn't see mentioned here yet: a lot of high-
| performance data center workloads don't actually go through the
| Linux kernel's network stack at all.
|
| 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.
| ssuds wrote:
| Key paragraph: "This energy savings comes with a caveat. "It is
| sort of a best case because the 30 percent applies to the network
| stack or communication part of it," Karsten explains. "If an
| application primarily does that, then it will see 30 percent
| improvement. If the application does a lot of other things and
| only occasionally uses the network, then the 30 percent will
| shrink to a smaller value.""
| Dwedit wrote:
| When your sentence contains "Up To", literally anything is
| possible.
___________________________________________________________________
(page generated 2025-04-21 23:01 UTC)