C state verhogen in Debian (DietPi)

[Church of Noise]

Sinds een poosje heb ik een licht (headless) servertje opgezet om o.a. Home Assistant op te draaien.
Omdat dat ding nu eenmaal 24/24 draait, poog ik het verbruik ervan terug te dringen (en als ik eerlijk ben, doe ik het ook omdat ik het leuk vind om er aan te tweaken).

De meest recente versie bestaat uit een HP 260 G3 met een Intel i3-7130u (die ik lichtjes ge-undervolt heb, al zal dat minimale impact hebben gezien de CPU load typisch tussen de 1 en de 5% ligt).
Het systeem draait DietPi, een lichtgewicht Debian, met daarboven dus Home Assistant (supervised, voor de connaisseurs ).
...

Als ik op vandaag in Powertop kijk, dan merk ik dat de C state van de Pkg werkelijk nooit boven C3 uitkomt.
Nu zal het verbruik dat typisch rond de 4W draait voor het hele systeem (gemeten met een Shelly Plug S) niet meer drastisch verminderen moest die C state omhoog kunnen, dan nog stoort het me enigzins.

Runnen van

code:

grep . /sys/devices/system/cpu/cpu0/cpuidle/state*/name

geeft

/sys/devices/system/cpu/cpu0/cpuidle/state0/name:POLL
/sys/devices/system/cpu/cpu0/cpuidle/state1/name:C1
/sys/devices/system/cpu/cpu0/cpuidle/state2/name:C1E
/sys/devices/system/cpu/cpu0/cpuidle/state3/name:C3
/sys/devices/system/cpu/cpu0/cpuidle/state4/name:C6
/sys/devices/system/cpu/cpu0/cpuidle/state5/name:C7s
/sys/devices/system/cpu/cpu0/cpuidle/state6/name:C8
/sys/devices/system/cpu/cpu0/cpuidle/state7/name:C9
/sys/devices/system/cpu/cpu0/cpuidle/state8/name:C10

De output van

lspci -vv | awk '/ASPM/{print $0}' RS= | grep --color -P '(^[a-z0-9:.]+|ASPM )'

is dit:

00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 (rev f1) (prog-if 00 [Normal decode])
                LnkCap: Port #1, Speed 8GT/s, Width x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 <4us
                LnkCtl: ASPM L0s L1 Enabled; RCB 64 bytes, Disabled- CommClk-
00:1c.2 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #3 (rev f1) (prog-if 00 [Normal decode])
                LnkCap: Port #3, Speed 8GT/s, Width x1, ASPM L1, Exit Latency L1 <16us
                LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 (rev f1) (prog-if 00 [Normal decode])
                LnkCap: Port #9, Speed 8GT/s, Width x4, ASPM L1, Exit Latency L1 <16us
                LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)
                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s unlimited, L1 <64us
                LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+
03:00.0 Non-Volatile memory controller: SK hynix BC501 NVMe Solid State Drive 512GB (prog-if 02 [NVM Express])
                LnkCap: Port #0, Speed 8GT/s, Width x2, ASPM L1, Exit Latency L1 <64us
                LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+

...

TLP is geinstalleerd, met volgende tweaks:
- CPU governor is powersave
- CPU energy policy power
- CPU boost uitgeschakeld
- Sched Powersave enabled
- PCI Express Active State Power Management (PCIe ASPM): powersupersaver

Ik heb ondertussen de driver van de Realtek RTL8111 al veranderd van de standaard r8169 die in de Debian kernel zit, naar de beter passende r8168 (en die zou ook betere C states moeten mogelijk maken).
Dat bleek geen verbetering te geven.

Vandaar: ik zou erg graag tips ontvangen rond welke stappen de C state kunnen verhogen.
Hoe kan ik bvb uitvissen of er bepaalde onderdelen (SK Hynix BC501 NVMe drive bvb) hogere C states tegenhouden?
...

[ Voor 45% gewijzigd door Church of Noise op 14-06-2023 19:58 ]

[deHakkelaar]

Niet veel reacties
Heb er niet veel verstand van maar had je deze al gecontroleerd:

Method 1
By booting with the kernel command line argument processor.max_cstate=0 the system will never enter a C-state other than zero.

https://www.golinuxhub.co...sableprocessorsleepstates

Geloof dat alstie gelimiteerd is met dat processor.max_cstate= kernel argument, dan zou die oa zichtbaar moeten zijn met onder:

code:

cat /proc/cmdline

Ter info:

$ man proc
[..]
       /proc/cmdline
              Arguments  passed  to the Linux kernel at boot time.  Often
              done via a boot manager such as lilo(8) or grub(8).

EDIT: Istie misschien zichtbaar hiero:

code:

sudo sysctl -a --pattern ".*state.*"

Of ze allemaal langs gaan (is lang):

code:

sudo sysctl -a

Ter info:

$ man sysctl
[..]
DESCRIPTION
       sysctl is used to modify kernel parameters at runtime.  The param‐
       eters available are those listed under /proc/sys/.  Procfs is  re‐
       quired  for  sysctl  support in Linux.  You can use sysctl to both
       read and write sysctl data.

[ Voor 23% gewijzigd door deHakkelaar op 16-06-2023 19:15 ]

[deHakkelaar]

Helemaal onderaan:
https://www.kernel.org/do...html?highlight=max_cstate

[mrmrmr]

@deHakkelaar Het is juist de bedoeling een hogere package C state te bereiken.

Hier staat inmiddels een crosspost van TS.

[deHakkelaar]

mrmrmr schreef op vrijdag 16 juni 2023 @ 19:58:
@deHakkelaar Het is juist de bedoeling een hogere package C state te bereiken.

Hier staat inmiddels een crosspost van TS.

Als er iets tegenhoud om een hogere C state te bereiken, dan kan dat die processor.max_cstate= parameter zijn.
Je zou hem ook voor de grap gewoon zelf als kernel parameter kunnen meegeven met een hoger C state als 3 (EDIT: mogellijk dat je dan de default kan beinvloeden).
Ik was nog zoekende hoe je deze limiet behoorlijk kunt achterhalen op 1 of andere manier.

[ Voor 4% gewijzigd door deHakkelaar op 16-06-2023 20:12 ]

[Cyphax]

Het is niet zo handig om er op twee plekken mee bezig te zijn, @Church of Noise wil je liever dit topic voortzetten of de gang van zaken in Church of Noise in "Het grote zuinige server topic - deel 3" ?

[Church of Noise]

Cyphax schreef op vrijdag 16 juni 2023 @ 20:37:
Het is niet zo handig om er op twee plekken mee bezig te zijn, @Church of Noise wil je liever dit topic voortzetten of de gang van zaken in Church of Noise in "Het grote zuinige server topic - deel 3" ?

Terecht punt, misschien beter in "Het grote zuinige server topic - deel 3", lijkt daar meer relevant...

[Cyphax]

Okee, dan sluit ik deze met nog een laatste verwijzing naar Church of Noise in "Het grote zuinige server topic - deel 3" voor de continuiteit