On Sun, 22 Sep 2024 11:55:18 +0200 Bastian Blank wrote: > On Sun, Sep 15, 2024 at 05:23:10PM +0200, Francesco Poli wrote: > > Or otherwise, if you think there's something wrong with them, could you > > please explain what is wrong? Maybe there's a way to fix them... > > The linux-cpupower package includes low level tools to interrogate and > set certain low level CPU features.
Dear Bastian, thanks for taking the time to reply. However, I only agree with part of your reasoning, see below. > So the reasons for installing this > package are two-fold, you either want to see various things, or you want > to globally change them. Exactly, I am encouraging you to make the change-operation more convenient for system administrators, who want to set something at boot (without having to manually invoke 'cpupower' after each boot or having to reinvent ad-hoc strategies). > But because of the two different usages, just > installing the package can not change global settings without futher > user interaction. > > Yes, we could provide them disabled. That's exactly what I am advocating: please ship the three files in the 'linux-cpupower' package, but install the systemd service disabled by default. Any sysadmin who wants to use the systemd service will have to edit the '/etc/default/cpupower' file anyway, hence no big deal if he/she also has to issue the following command: # systemctl enable --now cpupower.service > But overall we are currently at a > point, where even desktop environments have rudimentary settings for > this. Come on, not all Debian users run (sophisticated) desktop environments. My own desktop is built on Fluxbox, which is not even a desktop environment (just a standalone window manager): I am not aware of any cpupower-related settings in Fluxbox (are there any?). Anyway, Debian GNU/Linux machines may be up and running, without any logged-in user and/or without any desktop environment executing. Moreover, not all Debian GNU/Linux machines have desktop environments. What about (machines that only run) servers? Or HPC clusters? Network gateways? Embedded systems? A convenient mechanism to set cpupower-related things at boot would be useful for at least these cases... > And also basic cpu frequency is not longer a useful way to save > energy, but things like p states as used, which just shut of whole parts > of the chip. How are these things (like p states) managed? Could you please tell me more about them? > > About the files itself: please loose the shell wrapper. You can use > EnvironmentFile and multiple ExecStart with variable expansion (however > no conditionals). I had considered using multiple ExecStart directives. "No conditionals" is exactly the reason why I concluded that I had to go for the external script. Hence, I think that we cannot do without the external script... I reiterate the request to integrate the [three files] into the 'linux-cpupower' package, with the systemd service disabled by default. [three files]: <https://bugs.debian.org/894906#17> I acknowledge that they are probably sub-optimal and could be further generalized and/or enhanced. But, until someone comes up with a better solution, they are better than nothing... The current situation is that every user has to set up ad-hoc solutions (perhaps involving the deprecated 'rc.local' file or otherwise), unless he/she can leverage some desktop tool... And, of course, any of you from the Debian Kernel Team can further improve the files at any time. But, please, first ship the three files in the package, without waiting for the perfect solution. This bug report has been open since April 2018... As Voltaire once said, the better is the enemy of the good. Thanks for reading so far. Still hoping to see this bug fixed for good. Bye! -- http://www.inventati.org/frx/ There's not a second to spare! To the laboratory! ..................................................... Francesco Poli . GnuPG key fpr == CA01 1147 9CD2 EFDF FB82 3925 3E1C 27E1 1F69 BFFE
pgpnIuCKEu6zL.pgp
Description: PGP signature
