Linux Developers Ponder Decade-Old Decision To Disable PCI Runtime Power Management By Default

[Azrael5]

The decision has been a mistake such as the improvement on PCI-E/PCI power management removing just 3 lines of code after 12 years as of 5.8 kernel. Some improvements get benefits when they are almost useless because of modernity. Many ask the reason why Microsoft is preferred. This is one of the reasons.

[Hi-Angel]

I am confused. The commit that disabled power management says

This setting may be overriden by the user space with
the help of the /sys/devices/.../power/control interface

Alright, so I execute a `grep "" /sys/devices/*/power/control` and I see that every single device has "auto", PCI ones included. Docs say that control file has exactly two values "on" for disabled power management, and "auto" for it being enabled. Quoting:

The default for all devices is "auto", which means that they may be subject to automatic power management, depending on their drivers

So, what gives? Isn't it already the best possible setting, or do I misunderstand something?

[mulenmar]

Powertop is useful for figuring this out. It allows you to enable PM for each device to see if it has issues. I had an issue with a mouse that would switch of the Lazer after 1 second of not being used until a button was clicked - making it useless

I have the exact same problem if I enable powersaving blindly, though iirc the USB mouse takes a few more seconds to turn off on my end than yours.

Such USB device power savings seem to be the only issue on my desktop, thankfully.

[archkde]

This seems like something that should be enabled by the init system with a allowlist.

That's exactly what "can be overridden by userspace" means. So you're arguing that the change should happen in udev and not in the kernel.

[archkde]

I am confused. The commit that disabled power management says



Alright, so I execute a `grep "" /sys/devices/*/power/control` and I see that every single device has "auto", PCI ones included. Docs say that control file has exactly two values "on" for disabled power management, and "auto" for it being enabled. Quoting:



So, what gives? Isn't it already the best possible setting, or do I misunderstand something?

Something (udev rules or some power saving tool) has set these values already, or you actually have PCIe devices.

[sa666666]

All to often I see in these discussions that many people expect that users have cutting edge machines and that older systems are irrelevant nowadays. Why waste resources if they are still up to their task? Only last year I retired an aging 32-bit machine, not because it was lacking processor power, but only because I could not expand installed memory anymore past it's physical 750MB limit. But "newer" systems with max. 16-32GB are still quite capable to serve everyday tasks as indicated above, at least in a SOHO environment.

Because newer systems shouldn't have to suffer from bugs and workarounds in older hardware. I agree we should move to a blacklist for older systems, and enable things that will improve things going forward. Why should new computers be hobbled because of 10 year old hardware bugs? By all means, make sure old stuff doesn't break, but not at the expense of new stuff. We are moving forward, not backward, no matter what many people may wish to happen. I feel the same way about 32 vs. 64-bit. The sooner we can kill 32-bit, the better. Have options for it (virtualization, etc), but clearly mark is as being the exception to the rule, the outlier, etc. Otherwise we will never advance in this field.

[DanL]

I think the 16-bit ISA bus is still present in this form nowadays.

Yup. I think a lot of mobos still use ISA for Super I/O sensor chip connectivity. My B450 mobo:

[FONT=monospace][COLOR=#000000]00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)[/COLOR][/FONT]

[calc]

I am confused. The commit that disabled power management says

Alright, so I execute a `grep "" /sys/devices/*/power/control` and I see that every single device has "auto", PCI ones included. Docs say that control file has exactly two values "on" for disabled power management, and "auto" for it being enabled. Quoting:

So, what gives? Isn't it already the best possible setting, or do I misunderstand something?

I don't think what you showed above catches everything.

The following should:

find /sys/devices -iname control -exec grep -H "on" \{\} \; | sort

NOTE: the above will also show more than just pci power management.

Running the following should make them all good:

powertop --auto-tune

NOTE: You will probably need to add an exception for your usb input devices as others have mentioned. You can do that by running powertop without args and selecting which items you need to disable power management for, it will give you a command to run after the auto-tune line.

[camel_case]

Yup. I think a lot of mobos still use ISA for Super I/O sensor chip connectivity. My B450 mobo:

[FONT=monospace][COLOR=#000000]00:14.3 ISA bridge: Advanced Micro Devices, Inc. [AMD] FCH LPC Bridge (rev 51)[/COLOR][/FONT]

Isnt it used because of its Simplicity? ISA/LPC Interrupt lines are directly connected to the CPU. A benifit for small firmwares like BIOS. And compatibility: Generic drivers listen to default interupts.

[fransdb]

Because newer systems shouldn't have to suffer from bugs and workarounds in older hardware. I agree we should move to a blacklist for older systems, and enable things that will improve things going forward. Why should new computers be hobbled because of 10 year old hardware bugs? By all means, make sure old stuff doesn't break, but not at the expense of new stuff. We are moving forward, not backward, no matter what many people may wish to happen. I feel the same way about 32 vs. 64-bit. The sooner we can kill 32-bit, the better. Have options for it (virtualization, etc), but clearly mark is as being the exception to the rule, the outlier, etc. Otherwise we will never advance in this field.

I agree that older systems should not hamper progress. Advance all you want, but people should not be so arrogant to only count the newest gadgets as relevant. That said, I can live with the fact that we might need some switches to allow older systems to keep on running. As one participant already remarked: take an example from other OS'en.

There are still many 32-bit embedded processors, but they can't use Linux properly because some believe that 32-bit is not relevant anymore. Which is surely not true. Granted, a 32-bit server is not up to the tasks larger systems have. But as said before, for many SOHO tasks these systems are still enough - provided they have enough memory. But maybe I missed in the past the point that Linux developers might have become overconfident when they reached a small percentage market share? Is the goal still to have Linux on many desktops? Not with this strategy. As a response on the last few words of the above quote, advancement should not be the goal but rather a means to have and evolve an usable OS. (Said as a consumer, not as being a scientist)

Then again, Phoronix is rather focused on games, which have an ever greater appetite for processor power etc. fast, faster, but never fast enough!
So, it is no surprise that there are a lot of Phoronix supporters with probably deep pockets to have every 2-3 year "old" machines scrapped.