PowerTOP should have an "auto-optimize" setting that will not auto-tune "known-bad" devices

[WillNilges]

Hello, I have a ThinkPad T495 that runs Fedora 31. I noticed today that my Wacom tablet didn't work when unplugged. Someone on here suggested I checked TLP, so, naturally, I checked PowerTop. I flipped all turntables that had to do with USB ports, and the tablet works again. I don't think it's desirable to have USB shut off when --auto-tuneing. Is there a fix for that?

[WillNilges]

[nnmlss]

I have the same issue with the USB Logitec mouse/keyboard and what I found for a quick solution is to change the usb dongle to another usb port. Not so nice solution, but it is more quickly than to execute sudo powertop, authenticate with my password, navigate to Tunables tab and make Logitec USB reciever status to BAD. Using TLP DO NOT WORK, my logitec dongle ID is into the blacklist in tlp but everytime I restart the computer because of the powertop --auto-tune service I have enabled, the mouse and keyboard are lagggy until I change the port or make it with tunables status bad.

[thac0]

The auto-tune feature is intended to be a big hammer: flip all enumerated devices/settings to "good". Functionally speaking, auto-tune is doing what it was written to do.

What I think I'm reading is an ask for something akin to "auto-optimize", which would entail PowerTOP maintaining a "known-bad" list of devices. When run with "auto-optimize", PowerTOP would not tune devices/settings in said list.

[WillNilges]

Agree. After using it like that for a few months, it was never a huge inconvenience. If there was some way for it to recognize things such as wacom tablets and mice, that'd be sweet.

[pabs3]

I would also like this feature. It seems to me that at least initially, all mice/keyboards should not be enabled by auto-optimise, since they seem to be the most problematic devices.

[jtru]

I would also like to have this feature, but understand it's hard to implement - it's not easy to figure out which devices behave badly when "properly" tuned, and keeping a centralized list for this kind of policy to skip known-bad devices is probably downright impossible. So the only thing that makes sense is to make it easy for powertop users to choose and set a policy for which devices to consider themselves.

I started to scratch my own itch by (optionally) instead of having powertop emit all command to toggle tunables to GOOD via system(), printing them to stdout instead. That way, I can post-process these commands with whichever kind of tooling I choose to enact my local policy. Output of the patched executable with the switch enabled looks like this:

$ sudo ./src/powertop --auto-tune-dump --auto-tune 
modprobe cpufreq_stats failed
Loaded 0 prior measurements
Cannot load from file /var/cache/powertop/saved_parameters.powertop
File will be loaded after taking minimum number of measurement(s) with battery only 
RAPL device for cpu 0
RAPL Using PowerCap Sysfs : Domain Mask 5
RAPL device for cpu 0
RAPL Using PowerCap Sysfs : Domain Mask 5
Devfreq not enabled
glob returned GLOB_ABORTED
Cannot load from file /var/cache/powertop/saved_parameters.powertop
File will be loaded after taking minimum number of measurement(s) with battery only 

### VM writeback timeout
# echo '1500' > '/proc/sys/vm/dirty_writeback_centisecs';

### Enable SATA link power management for host5
# echo 'med_power_with_dipm' > '/sys/class/scsi_host/host5/link_power_management_policy';

### Enable SATA link power management for host3
# echo 'med_power_with_dipm' > '/sys/class/scsi_host/host3/link_power_management_policy';

### Enable SATA link power management for host1
# echo 'med_power_with_dipm' > '/sys/class/scsi_host/host1/link_power_management_policy';

### Enable SATA link power management for host4
# echo 'med_power_with_dipm' > '/sys/class/scsi_host/host4/link_power_management_policy';

### Enable SATA link power management for host2
# echo 'med_power_with_dipm' > '/sys/class/scsi_host/host2/link_power_management_policy';

### Enable SATA link power management for host0
# echo 'med_power_with_dipm' > '/sys/class/scsi_host/host0/link_power_management_policy';

### Runtime PM for I2C Adapter i2c-0 (SMBus PIIX4 adapter port 0 at 0b00)
# echo 'auto' > '/sys/bus/i2c/devices/i2c-0/device/power/control';
[...]

Do you think this would be a worthwhile addition to powertop, and if so, would you prefer a pull request or a patch posted (like mention in this repo's description) to powertop@lists.linuxfoundation.org?

[pabs3]

@jtru I'm not a PowerTOP developer but that sounds like a useful feature, please do submit it. The mailing list looks fairly inactive, and pull requests seem to get merged, so that seems like the way to go. Might be worth doing both just in case.

My current workaround for this issue is to run auto-tune and add a systemd dropin that runs a script that turns on problematic devices after the auto-tune has been run. It might be worth also adding a feature to configure exceptions to the auto-tune feature.

$ head -vn-0 /etc/systemd/system/powertop.service.d/pabs-workarounds.conf /usr/sbin/pabs-powertop-workarounds 
==> /etc/systemd/system/powertop.service.d/pabs-workarounds.conf <==
[Service]
ExecStart=pabs-powertop-workarounds

==> /usr/sbin/pabs-powertop-workarounds <==
#!/bin/sh
set -e
# FIXME: add support to usbutils for manipulating power control
# FIXME: add support to usbutils for selecting multiple devices
# FIXME: add support to powertop for autotune exceptions
for f in /sys/bus/usb/devices/*/ ; do
    # Mouse/keyboard devices are often bad
    if grep -qE '^000$' "$f/idVendor" 2> /dev/null &&
       grep -qE '^(0000|0000)$' "$f/idProduct" 2> /dev/null ; then
         echo on > "$f/power/control"
    fi
    if grep -q '^0000$' "$f/idVendor" 2> /dev/null &&
       grep -q '^0000$' "$f/idProduct" 2> /dev/null ; then
         echo on > "$f/power/control"
    fi
done

[fenrus75]

it's a little hard to know what is safe and what isn't... but we're all for making things better

On Fri, Jan 6, 2023 at 6:26 PM Paul Wise @.***> wrote:

@jtru https://github.com/jtru I'm not a PowerTOP developer but that sounds like a useful feature, please do submit it. The mailing list looks fairly inactive, and pull requests seem to get merged, so that seems like the way to go. Might be worth doing both just in case.

My current workaround for this issue is to run auto-tune and add a systemd dropin that runs a script that turns on problematic devices after the auto-tune has been run. It might be worth also adding a feature to configure exceptions to the auto-tune feature.

$ head -vn-0 /etc/systemd/system/powertop.service.d/pabs-workarounds.conf /usr/sbin/pabs-powertop-workarounds ==> /etc/systemd/system/powertop.service.d/pabs-workarounds.conf <== [Service] ExecStart=pabs-powertop-workarounds

==> /usr/sbin/pabs-powertop-workarounds <==

!/bin/sh

set -e

FIXME: add support to usbutils for manipulating power control

FIXME: add support to usbutils for selecting multiple devices

FIXME: add support to powertop for autotune exceptions

for f in /sys/bus/usb/devices/*/ ; do

Mouse/keyboard devices are often bad

if grep -qE '^000$' "$f/idVendor" 2> /dev/null && grep -qE '^(0000|0000)$' "$f/idProduct" 2> /dev/null ; then echo on > "$f/power/control" fi if grep -q '^0000$' "$f/idVendor" 2> /dev/null && grep -q '^0000$' "$f/idProduct" 2> /dev/null ; then echo on > "$f/power/control" fi done

— Reply to this email directly, view it on GitHub https://github.com/fenrus75/powertop/issues/38#issuecomment-1374353931, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ54FLD5LD457HQFPNJXBDWRDH65ANCNFSM4KVKQZGQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[jtru]

Thanks for chiming in and confirming this could be useful :)

I am not a C++ developer by any means, but I pushed what I have to my fork of this repo available at https://github.com/fenrus75/powertop/compare/master...jtru:powertop:auto-tune-dump

In the hope you find this contribution useful, I will also post the resulting patch to the mailing list, since that is, afaiui, the preferred way of submitting patches.

[pabs3]

The patch looks good to me (not a PowerTOP dev).

AFAICT more patches get merged via GitHub pull requests than via patches to the mailing list.

-- bye, pabs

https://bonedaddy.net/pabs3/

[dinvlad]

Could you please let us know if this PR will be submitted?

[jtru]

It's been merged in #116 :)