Land the configuration Dell Ubuntu edition laptops used to pass e-star

[alex-tu-cc]

To pass e-star7 , the tlp configuration need to be changed. This is that one we are currently passed e-star7 and all Dell Ubuntu edition enabled with Bionic are all included this configuration to pass e-star7 compliance. http://paste.ubuntu.com/p/wq2XhnR4XN/

I would like to contribute back that configuration that Dell Ubuntu edition used to pass e-star7. So, that likely every laptop use the same configuration can save as much power as what e-star7 required.

How do you think?

[linrunner]

Hi,

thanks for your input.

Your config is based on 1.1 which is a bit outdated. Are you affiliated with Dell? I suggest to use TLP 1.2.2 for the preload image.

Regarding your proposed changes:

-DISK_IDLE_SECS_ON_AC=0
+DISK_IDLE_SECS_ON_AC=2

Imho it doesn't make sense to enable laptop mode on AC power. I'm not convinced about the benefit either.

 -MAX_LOST_WORK_SECS_ON_AC=15
 +MAX_LOST_WORK_SECS_ON_AC=60

This would slightly increase the risk of data loss for users who remove their battery on AC – or desktop users with TLP installed by default (e.g. Manjaro). I'm not convinced about the benefit.

-SCHED_POWERSAVE_ON_AC=0
+SCHED_POWERSAVE_ON_AC=1

Is there still hardware / kernels supporting this? I haven't seen the sysfile in ages. Maybe I should remove the feature alltogether ...

-ENERGY_PERF_POLICY_ON_AC=performance
+ENERGY_PERF_POLICY_ON_AC=default

This is already covered in the master branch (https://github.com/linrunner/TLP/commit/81a99c0b531101c93f7953aedcf966bedca4e2de), the new parameter is:

CPU_ENERGY_PERF_POLICY_ON_AC=balance_performance

-DISK_APM_LEVEL_ON_AC="254 254"
+DISK_APM_LEVEL_ON_AC="100 100"
-DISK_APM_LEVEL_ON_BAT="128 128"
+DISK_APM_LEVEL_ON_BAT="100 100"

I fear this could be too aggressive for older hard disk drives, causing excessive load cycle counts. Even 128 was too aggressive for some. May be ok for new, specified drives, but not in general. Btw: are there really hard drives in Dell laptops currently on sale?!

-#DISK_SPINDOWN_TIMEOUT_ON_AC="0 0"
+DISK_SPINDOWN_TIMEOUT_ON_AC="2 2"
-#DISK_SPINDOWN_TIMEOUT_ON_BAT="0 0"
+DISK_SPINDOWN_TIMEOUT_ON_BAT="2 2"

I won't enable hard disk spin down by default. It's pointless for the system drive, because it'll always spin up after a short timespan even in idle (wearing the drive unneccessarily) and it'll cause a significant delay upon access (after spin down). Imho it's better to leave it up to the user to explicitly enable this.

-SATA_LINKPWR_ON_AC="med_power_with_dipm min_power"
+SATA_LINKPWR_ON_AC="med_power_with_dipm max_performance"

This change will have no effect for kernels >= 4.15 because med_power_with_dipm has precedence. Are there older kernels in the Dell preload images?

-#AHCI_RUNTIME_PM_ON_AC=on
-#AHCI_RUNTIME_PM_ON_BAT=on
+AHCI_RUNTIME_PM_ON_AC=on
+AHCI_RUNTIME_PM_ON_BAT=on

Are you sure? on means PM disabled, auto enabled. Anyway, i won't enable this anytime soon, because it caused hard freezes on my machines at the time i implemented the feature.

-PCIE_ASPM_ON_AC=performance
+PCIE_ASPM_ON_AC=default
-PCIE_ASPM_ON_BAT=powersave
+PCIE_ASPM_ON_BAT=default

This was already changed back in 1.2: https://github.com/linrunner/TLP/issues/344

-RADEON_POWER_PROFILE_ON_AC=high
+RADEON_POWER_PROFILE_ON_AC=default

This was already changed back in 1.2: https://github.com/linrunner/TLP/commit/c8c1fd5f73d0ba8aaf8a55f378eb4bff7d4ef5fd. But is there really new Dell hardware where the driver uses this instead of the newer DPM?

-WIFI_PWR_ON_AC=off
+WIFI_PWR_ON_AC=on ***

All right, let's give this a try for 1.3 ...

-SOUND_POWER_SAVE_ON_AC=0
+SOUND_POWER_SAVE_ON_AC=1

Having this disabled on AC is already a compromise because of way too many user complaints in the past. No change.

-RUNTIME_PM_ON_AC=on
+RUNTIME_PM_ON_AC=auto

I don't see a benefit here.

-#RUNTIME_PM_DRIVER_BLACKLIST="amdgpu nouveau nvidia radeon"
+RUNTIME_PM_DRIVER_BLACKLIST="nouveau"#

What's the intention here? nouveau is effective even when the line is commented (see docs). Removing the others will cause trouble with users relying on them for proper hybrid operation.

-USB_BLACKLIST_PRINTER=1
-USB_BLACKLIST_PRINTER=0

This will cause trouble with many USB printers. No change.

-USB_BLACKLIST_WWAN=1
+USB_BLACKLIST_WWAN=0

This was already changed back in 1.2: https://github.com/linrunner/TLP/commit/344c699a25780fdfdc3cc1701fc9693aa7141b8d

[alex-tu-cc]

Thanks for the response and sorry for my late response, it's busy recently.

I agree it could trigger a lot of issues that we aggressively enable all autosuspend by default.

So, how about to have a way to let the user override the configuration easier so that we can share the verified configuration which passed e-star by something like meta-package as a plugin.

the idea could be: let user put custumized configuration under /etc/default/tlp.d/ , then tlp daemon check /etc/default/tlp.d/xxx.conf to override configuration before start working.

On Dell Ubuntu edition, we put that aggressive configuration in /etc/default/tlp.d/ then override /etc/default/tlp during installation time. It's not perfect but could be a way to land different verified configurations for different platforms.

for example: the idea 1. we can have a platform meta package carry the verified TLP configuration so that each platform can have different fine-tuned tlp configuration.

idea 2. we can land different platform-specific tlp configurations to TLP packages so that end-user can pick the one for his platform to enjoy our effort for power-efficiency.

On both ideas, user can easily roll back to the default setting by deleting configurations in /etc/default/tlp.d/ if they encountered issues.

[alex-tu-cc]

For the target to let all user using machines which Ubuntu certified and passed e-star can get the same efficiency power consumption.

A draft proposal would be to keep putting the different configuration for each certified machine that passed e-star. So that user has an option to enjoy it.

Then extend tlp commands: e.g. tlp suggesion If user executes tlp suggesion on machine which certified and passed e-star , then it print:

Congratulations! This machine is certified and exists customized configuration which passed e-star. Do you want to give it a try? (Y/n)

Then user answer Yes. We copy prepared configuration from /usr/lib/tlp/certified-confs/${BIOS_ID} to /etc/default/tlp.d/ Then users can enjoy the verified configuration without risk. (because it is verified by Canonical)

In case the user gets regression somehow, the user can execute tlp reset-default (another extend command) to roll back to the default configuration.

I will try implement it in my spare time, welcome suggestions on this idea.

[linrunner]

There is a fundamental problem with the *tlp.conf.d/.conf** approach, which is why i haven't implemented it yet:

If you split the config and read all files sequentially, the last read file wins. This could mean that for a given parameter /etc/default/tlp wins or /etc/tlp.conf.d/dell-platform-xyzzy.conf wins or /etc/tlp.conf.d/user-defined.conf wins. Depending on the lexical sequence of filenames and whether the parameter is commented or not.

This makes it difficult for the user to find out which setting is actually effective. tlp-stat -c may help a little, but TLP's fundamental paradigm is to have all settings in one file for maximum clarity.

Besides it breaks tools like TLPUI which rely on a single /etc/default/tlp.

However your request for a platform-specific configuration is important to me.

I won't drop that paradigm lightly but i'm always open for creative ideas.

Btw: /etc/default/ is a Debian / Ubuntu specific config dir. Better would be /etc/tlp.conf.d/ – and moving /etc/default/tlp to /etc/tlp.conf of course ... ;)

Also refer to https://github.com/linrunner/TLP/issues/398

[linrunner]

Btw: are you interested to help here?

[alex-tu-cc]

Thanks for your detail explanation. I revised my patch which might solve your concerns: https://github.com/linrunner/TLP/pull/435

for issue #379 , it looks a feature request for Dell, you might issue it to their official bug report system : https://bugs.launchpad.net/dell-sputnik

[linrunner]

idea 2. we can land different platform-specific tlp configurations to TLP packages so that end-user can pick the one for his platform to enjoy our effort for power-efficiency.

After the conf.d foundation is done, what about TLP detecting the platform itself and choosing a matching config file?

We could introduce one more directory like /usr/share/tlp/platform.d where a Dell specific package puts config files for Dell platforms. In that way you may maintain it independently.

[linrunner]

@alex-tu-cc: wrote:

Do you have a schedule to release it(it's beta version)? Because of the Debian Import Freeze date of Ubuntu 20.04 is February 27th. I'm thinking that if we are lucky to get this new change into next Ubuntu LTS,

I'm well aware of the dates. But we wouldn't want to be doing ourselves the favor of forcing something immature into the LTS. For me it depends on the progress of the beta test.

I would be very grateful if you could recruit additional participants from your environment. I have prepared a PPA to facilitate updates.

Beta Test: https://github.com/linrunner/TLP/issues/449 PPA: https://launchpad.net/~linrunner/+archive/ubuntu/tlp-beta/

[linrunner]

@alex-tu-cc : for 1.4 I need you input on my above idea:

After the conf.d foundation is done with 1.3, what about TLP detecting the platform itself and choosing a matching config file?

We could introduce one more directory like /usr/share/tlp/platform.d where a Dell specific package puts config files for Dell platforms. In that way you may maintain it independently.

[alex-tu-cc]

Your idea is awesome that collects customized configuration then let TLP choose what configuration is best.

But there's a problem that the target TLP configuration might depend on some extra DKMS or workaround which installed by platform meta-package dependency. So, TLP is hard to judge if the environment is qualified enough to use the suggested configuration.

We have a plan to introduce platform meta by the installer of 20.04 so that we can suggest user to install needed DKMS and workaround. (detect platform automatically then suggest the best meta)

Based on the design of platform meta, my plan is to land customized TLP configuration by platform meta package. So, that we can make sure all environment is same as verified. And the current 1.3 is mature enough to support this idea. :)

In most cases, we just use the default aggressive TLP configuration without customization to pass E-star compliance. Customization mostly introduced by problematic BIOS/hardware/firmware or kernel drivers. That means the customization could be retired while issues are fixed. Before that, we plan to put know issues and needed customization on launchpad public bug or wiki, so that people know issues and why and what TLP customization is needed. (of cause they can just trust the meta-package that 20.04 installer suggests) Base on this situation, to host customization configuration in another meta-package is more convenient.

To achieve the idea above, I might need your help to provide an aggressive configuration as an extra option for users to set their machines to power-saving mode. If any driver regression introduced by aggressive power policy should be looked during enablement. The idea scenario of that aggressive configuration would be:

1. all certified machines should able to works well with aggressive configuration.
2. non-certified machines can also try the aggressive configuration because the solutions came out from certification machines should eventually backport to stock Ubuntu.

How do you think?

BTW, I'm interested in testing 1.3 beta. From my latest result the config.d structure works well. (test case: put customization on each config.d , then verify it by tlp-stat) Or do you have a test plan that points out what tests must be done?

[linrunner]

What I have in mind is much simpler. Just some string matching against **/sys/class/dmi/id/***:

56-thinkpad.conf

[board_name:20KGS03800]
PARAM1="value1"
PARAM2="value2"

Could also be more than one platform per file.

BTW, I'm interested in testing 1.3 beta.

Atm it's mostly visual inspection. In beta.3 i added file and lineno where the parameter comes from to the tlp-stat -c output. Plus i have a file 97-fuzz.conf to "annoy" the parser

 X=a
Y=a b c
Z="abc    
T="abc"                     
U=
V="a"                                            
W= "xyz"
Q=abcd
R='äöü'
S='ixyu

I'll upload beta.3 to the PPA this evening (probably).

[linrunner]

ps. I don't mind about other dependencies like packages, drivers et. al. That's not within the scope of TLP. You give TLP match strings and parameters and that's it. The rest should be solved by your factory image process ...

[alex-tu-cc]

hmm.. there's a BIOS issue just came to my mind. Dell told us that they will not promise the DMI string is consistent after the BIOS upgrade. So we changed meta-package to associate PCI subsystem ID instead.

It would be a risk if we associate customization just to DMI string.

How about to add a new flexible option to associate configuration with PCI information like modealase of packages. So that customization can not only be hooked to a platform but also a device.

e.g. [pci:sv00001028sd0000080C] PARAM1="value1" PARAM2="value2"

e.g. [pci:v00008086d0000A370svsd00001030bcsci] PARAM1="value1" PARAM3="value3"

If we have that option, we can upstream customization to TLP each time a new platform be verified, so that the customization can be enjoyed across distributions.

Before that option, TLP 1.3 is good with Ubuntu 20.04, because the platform meta package can achieve a similar result. (e.g. land file to /etc/tlp.d/99-platformA.conf)

BTW, are you convenient to suggest a most aggressive TLP configuration? so that I can not only visual inspection but also measure the power on a machine to make sure things are working as expected.

It's Lunar New Year here, I might response later after vocation :)

[linrunner]

Additional tlp-readconf code must be as simple and fast as possible. The new scheme already costs quite some performance.

• Where in /sys/ can I read the PCI information?
• Is it per laptop model or is it for single components?

[alex-tu-cc]

To cover both laptop models and single component will have better flexibility. The idea is to apply the config one by one by modealiase just like what kernel modules are counting on. e.g. [pci:sv00001028sd0000080C] ; Apply to Dell machines which have subID 080C PARAM1="value1" PARAM2="value2"

e.g. [pci:v00008086d0000A370svsd00001030bcsci] ; Apply to Intel device Device ID=A370 SubID=1030 PARAM1="value1" PARAM3="value3"

note: all this information can be get by sudo udevadm info -e | less

for Dell laptops, the unique ID for models can be got by cat /sys/devices/pci0000:00/0000:00:00.0/subsystem_device, but it might not be applied to other OEM.

maybe we can leverage some other tools like ubuntu-drivers devices in this case. It's a possible way either to pick code logic from ubuntu-drivers or patch ubuntu-drivers to have an extra option to distinguish alias that user input. For example to propose a new option --check-alias

$ ubuntu-driver --check-alias pci:sv00001028sd0000080C
Yes, it matches this machine.

[linrunner]

@alex-tu-cc : on demand parsing of all the udevadm output and matching with a myriad platform.conf files would be far to clumsy and slow. That is more likely to happen as a manual preparation step (like your initial suggestion).

Nor do I want an Ubuntu-only tool.

Some time ago I read a piece on hwdb. That's a starting point perhaps.

[alex-tu-cc]

@linrunner I understand the point. BTW, I'm preparing a new process for Ubuntu based on TLP 1.3 to reach my initial plan. I will also share it to you when it's mature enough. :)

[linrunner]

@alex-tu-cc : any news?