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.
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.
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.
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
> 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.
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)
Also no you are entirely unaffected by this unless you use a very specific and uncommon syscall.
Like others have mentioned, it's just a huge deal in the data center now. With that comes a lot of influence by corporates interests.
Whereas BSD has gone the opposite way. Started by Berkeley but abandoned to the community. Business is not really interested in that because anything they contribute can be used by anyone for anything (even their competitors can use it in closed source code). Netflix was the biggest user but I don't think they contribute anymore either. WhatsApp used it until Facebook acquired them. That leaves netgate and ix systems which are small. Netgate pushed a really terrible wireguard once but it was nipped in the bud luckily. https://arstechnica.com/gadgets/2021/03/buffer-overruns-lice... It also highlighted many trust issues which have been improved since.
Of course whether this is an issue for you is very personal. For me it is but clearly for a lot more people it isn't, as Linux is s lot more popular.
Arguably, the only somewhat mainstream operating systems today that deserve that label are the *BSDs. Haiku OS gets an honorable mention but I wouldn't consider Haiku OS to be mainstream.
> Arguably, the only somewhat mainstream operating systems today that deserve that label are the *BSDs.
I think the word you're looking for is 'sidelined'.
But yeah grassroots was perhaps not the right term. I meant the status quo, not the origin. I don't know what the right word is then though.
I'm expect there are many, but the vast majority are likely massive datacenters with hundreds of thousands of machines each running multiple instances, and also Android phones are probably more common than home equipment. Edit: Also IoT, as someone else points out.
I would be shocked if I am incorrect.
I suggest you reread “software used in datacenters (e.g. by CDNs) that does use it”. This is not a reference to software in a datacenter. It is a reference to software in a datacenter that uses it, which is a subset of the former.
Who in their right mind would leave something so critical to the success of their product to a general purpose OS designed for mainframes and slightly redesigned for PCs?
(I typed this on Linux PC).
This is specifically a change to the Linux kernel, which is much, much more broadly successful.
The article name is, Data Centers Can Slash Power Needs With One Coding Tweak: Reworking 30 lines of Linux code could cut power use by up to 30 percent
The article says, “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.”
It seems you only read the HN title? If so, why bother to critique the article's title?
They mix interrupts and polling depending on the load. The interrupt service routine and user-kernel context-switch overhead is tiny computationally and hence in power usage.
Also, most network hardware in the last twenty years has had buffer coalescing, reducing interrupt rates.
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.