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

Re:Reworking 30 lines of Linux code could cut power use by u... by Denvercoder9 on Monday April 21, 2025 @02:00PM (#43754645)

> 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.

[ Parent | on HN ]

Re:Reworking 30 lines of Linux code could cut power use by u... by p_l on Monday April 21, 2025 @04:04PM (#43755868)

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

[ Parent | on HN ]

Re:Reworking 30 lines of Linux code could cut power use by u... by Denvercoder9 on Tuesday April 22, 2025 @02:47AM (#43759640)

The article is terrible, this doesn't affect the default NAPI behaviour. See the LWN link posted elsewhere for a more detailed, technical discussion. From the patch set itself:

> If this [new] parameter is set to a non-zero value and a user application has enabled preferred busy poll on a busy poll context (via the EPIOCSPARAMS ioctl introduced in commit 18e2bf0edf4d ("eventpoll: Add epoll ioctl for epoll_params")), then application calls to epoll_wait for that context will cause device IRQs and softirq processing to be suspended as long as epoll_wait successfully retrieves data from the NAPI. Each time data is retrieved, the irq_suspend_timeout is deferred.

[ Parent | on HN ]