Live data from Hacker News

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

spectrum.ieee.org

111–120 of 123 posts

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

#111
post #5

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’s a lot more nuanced than that. Being in a data center doesn’t imply heavy network utilization.

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.

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

#112
post #78

Earlier quoted context omitted.

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

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

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.

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

#113
post #110
post #86

Earlier quoted context omitted.

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.

Linux has been a corporate project for at least 20 years.

That roots part in grassroots means something.

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

#114
post #86

Earlier quoted context omitted.

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.

It was originally, yes. There's a lot of corporate influence now (just look at the monthly kernel submissions). https://news.itsfoss.com/huawei-kernel-contribution/ 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 interes…

No it's not an issue to me, just pointed out a factual mistake.

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

#115
post #77

I thought that Intel added the ‘pause’ instruction to make busy spinning more power friendly

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 ma…

It had REP NOP which is the same opcode as PAUSE, but on CPUs that supported it PAUSE does less work for the same effect. At least that's my understanding of it.

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

#116
post #113
post #110

Earlier quoted context omitted.

Linux has been a corporate project for at least 20 years.

That roots part in grassroots means something.

Yes, but I don't think it means what you think it means? Just because Linux was developed by basement dwelling hackers 20+ years ago, doesn't make it a grassroots project.

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.

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

#117
post #14

Earlier quoted context omitted.

Without looking at stats, I would think android phones.

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.

It's Android/Linux, not GNU/Linux.

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

#118
post #116
post #113

Earlier quoted context omitted.

That roots part in grassroots means something.

Yes, but I don't think it means what you think it means? Just because Linux was developed by basement dwelling hackers 20+ years ago, doesn't make it a grassroots project. 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.

It quite literally makes it a grassroots project.

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

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

#119
post #118
post #116

Earlier quoted context omitted.

Yes, but I don't think it means what you think it means? Just because Linux was developed by basement dwelling hackers 20+ years ago, doesn't make it a grassroots project. 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.

It quite literally makes it a grassroots project. > 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'.

Meh not really. I'm running BSD with the very latest software. KDE, Firefox, Chrome, LibreOffice. All rolling unlike most Linux distros. I really don't care how 'big' my OS is.

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.

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

#120
post #78

Earlier quoted context omitted.

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

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")),…

[deleted]
Post reply on HN