From ArchWiki

Why using Powertop over TLP?

If I read the LP FAQ ( Why use TLP? I applied power save settings with powertop already

Powertop isn't a power management tool but merely an analysis tool. Any recommended settings you apply with powertop get lost upon the next system reboot. To make powertop's settings permanent you need a tool like TLP.

TLP's default configuration contains all appropriate powertop recommendations and implements them automatically. << this line

--Beta990 (talk) 27 May 2014 (UTC)

Please sign your posts. One reason I see to just use powertop over TLP is that the latter's more advanced features take more care to implement correctly for a specific machine, some being very model/hardware specific. Great tool for sure.
--Indigo (talk) 10:38, 29 May 2014 (UTC)Reply[reply]

Adding method that isn't listed

this reversion is based on the recommended list above, however that list of recommendations doesn't cover using tmpfiles.d as a method. Please advise? -- storrgie 13:50, 3 November 2017 (UTC)Reply[reply]

There is a better way to disable the NMI watchdog: Power_management#Disabling_NMI_watchdog. As for the tmpfiles.d in general, see the note at the end of the systemd#Temporary_files section. -- Lahwaacz (talk) 18:58, 3 November 2017 (UTC)Reply[reply]
So you reverted under one premise, now you've dug up two others because your original premise doesn't make sense. Is the wiki overall better due to this reversion? Do you think people searching for applying powertop will also stumble upon the systemd#Temporary_files section... I certainly did not. -- storrgie 23:59, 3 November 2017 (UTC)Reply[reply]
As mentioned in the "recommended" way, you should read the Power management page for details. Its Power_management#Power_saving section contains all tweaks suggested by powertop along with a suitable config snippet. systemd's tmpfiles are not used even once, so there is no reason why the systemd#Temporary_files section should be made prominent. And of course there is no reason to duplicate tips mentioned in other parts of the wiki. -- Lahwaacz (talk) 08:15, 4 November 2017 (UTC)Reply[reply]
It is not mentioned elsewhere in the wiki within this context, I do not view it as a duplication. I believe your reversion is overzealous however I must defer to you as an admin of the wiki. Reverting every proposed modification from me does however create a strong disincentive to further contribution. -- storrgie 13:34, 4 November 2017 (UTC)Reply[reply]
We could add a note that Systemd tmpfiles.d is not recommended, see systemd#Temporary_files for detail. There are other tmpfiles usages that may need clean up too. --Fengchao (talk) 03:41, 16 November 2017 (UTC)Reply[reply]

Powertop.service file Requires= and After= sense

@Lahwaacz reverted my edit that adds:


to the powertop.service file because these additions would not make any sense.

On my system, without these two lines, reaching is delayed by over 2.2 seconds caused by "powertop.service" according to systemd-analyze critical-chain: @5.086s

└─powertop.service @2.883s +2.202s

  └─ @2.824s

That is 78% longer, then without. To me, a 78% longer boot time makes sense. With Requires and After the is reached in 2.85 seconds: @2.853s

└─systemd-logind.service @2.750s +102ms

  └─ @2.685s Probackup-nl (talk) 13:58, 21 January 2024 (UTC)Reply[reply]

So what? The service is still starting in the background, it just does not show up in the critical chain. You don't get any $$ save, only virtual 2.2 seconds gain. This is not much to justify placing and along with in the same service. If you absolutely need to save 2.2 seconds, make a timer with OnBootSec that will trigger the service and remove — Lahwaacz (talk) 14:24, 21 January 2024 (UTC)Reply[reply]
Making a timer is more hassle. How bad is using "" instead of "Requires and"? Probackup-nl (talk) 15:13, 21 January 2024 (UTC)Reply[reply] may be an alias to which is started after so that's even worse. After= is intended for ordering services within the same target, or targets within the startup sequence. Using it for overriding the order of one service relative to a unit outside the target that wanted it is not appropriate. — Lahwaacz (talk) 15:39, 21 January 2024 (UTC)Reply[reply]