PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : CPU Takt wird nicht nach ganz unten geregelt



Bayerfans04
29.12.11, 13:30
Hallo,

ich habe Fedora 15 (Kernel 2.6.41.4-1). Meine CPU (Intel i7-2630QM) wird bei Volllast korrekt auf den Maximaltakt



# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
2001000

hochgeregelt, im Leerlauf jedoch nur auf


# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
1600000

runtergeregelt, obwohl bis zu 800 Mhz möglich sind:


# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_available_frequencies
2001000 2000000 1900000 1800000 1700000 1600000 1500000 1400000 1300000 1200000 1100000 1000000 900000 800000


Die Auslastung der CPUs ist aber bei 0%. Habt ihr eine Idee, woran das liegen kann?

Ich danke euch.

Ede
31.12.11, 10:43
Schau noch das:

# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
Da kannst du einstellen, bis zu welcher Frequenz runter geregelt werden soll.

Ich habe mal ein ähnliches Problem beschrieben:
http://www.linuxforen.de/forums/showpost.php?p=1774787&postcount=81
600 MHz als untere Grenze, was für meinen Geschmack zu hoch ist. Mit dem alten Treiber ging das unter 100 MHz runter.

Bayerfans04
31.12.11, 11:08
Die minimale Frequenz ist auch hier auf 800 Mhz gesetzt. Ich sehe aber gerade, dass scaling_cur_freq und cpuinfo_cur_freq unterschiedliche Werte anzeigen, ist das normal / wo ist der Unterschied?



# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
800000
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_cur_freq
800000
# cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq
1600000


Kann der CPU dabei irgendwas passieren, wenn ich die Taktrate auf 600 heruntersetze? Muss ich das dann in der scaling_min_freq UND scaling_available_frequencies setzen?

Ede
31.12.11, 12:27
Die minimale Frequenz ist auch hier auf 800 Mhz gesetzt.
Hier auf 600.


Ich sehe aber gerade, dass scaling_cur_freq und cpuinfo_cur_freq unterschiedliche Werte anzeigen, ist das normal / wo ist der Unterschied?
Weiss ich nicht. Bei mir haben beide immer denselben Wert.


Kann der CPU dabei irgendwas passieren, wenn ich die Taktrate auf 600 heruntersetze?
Nein, da kann nichts kaputt gehen. Unzulässige Werte ignoriert der Treiber. Spiel da einfach ein bisschen rum.


Muss ich das dann in der scaling_min_freq UND scaling_available_frequencies setzen?
Nur in scaling_min_freq. scaling_available_frequencies ist vom Treiber vorgegeben und kann nicht verändert werden.

Das Modul acpi_cpufreq hat einen Parameter acpi_pstate_strict.

# modinfo acpi_cpufreq
filename: /lib/modules/2.6.37.6-0.9-default/kernel/arch/x86/kernel/cpu/cpufreq/acpi-cpufreq.ko
alias: acpi
license: GPL
description: ACPI Processor P-States Driver
author: Paul Diefenbaugh, Dominik Brodowski
srcversion: 513F747D3E9E884F1A0364A
depends: processor,mperf
vermagic: 2.6.37.6-0.9-default SMP mod_unload modversions 586TSC
parm: acpi_pstate_strict:value 0 or non-zero. non-zero -> strict ACPI checks are performed during frequency changes. (uint)
Könnte man sich noch genau informieren, was das macht.

Bayerfans04
31.12.11, 12:42
Eine andere niedrigere Minimalfrequenz als 800 Mhz wird nicht angenommen.

Scheinbar ist es so, dass cpuinfo_cur_freq die tatsächliche Frequenz anzeigt und scaling_min_freq die Frequenz, die der governor, scheinbar erfolgslos, anweist.

Kennt jemand den Grund, wieso die CPU nicht auf 800Mhz gedrosselt werden kann?

Edit:

Mein i7 2630 hat vier physikalische und 4 virtuelle Kerne (couinfo zeigt auch 8 Kerne). Kann es sein, dass jeder einzelne der 8 Kerne mit 800 Mhz läuft, der physikalische daher mit 1600 Mhz?

Ede
31.12.11, 12:59
Zeig mal, was du eingibst, um die Frequenz zu ändern.

Bayerfans04
31.12.11, 13:05
Zeig mal, was du eingibst, um die Frequenz zu ändern.



# echo 700000 | sudo tee /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
700000
# cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
800000


Wenn ich z.B. 810 Mhz eingebe, wird es auch angenommen, scheinbar ist bei 800 Mhz wirklich Schluss, schade. Gerade bei 4 Kernen würden 500 Mhz oder noch weniger im Leerauf doch locker reichen..

Ede
31.12.11, 13:12
Ja, bei 800 Mhz ist bei dir Schluss. Das zeigt ja auch scaling_available_frequencies.

Bayerfans04
02.01.12, 12:51
Hat jemand eine Idee, wieso cpuinfo_cur_freq auf 1600 Mhz anzeigt, obwohl scaling_cur_freq auf 800 steht?

Bayerfans04
05.01.12, 02:23
Ich habe gerade etwas sehr interessantes herausgefunden:

Obwohl ich annahm automatische Updates deaktiviert zu haben, wurde letztenes mein Kernel aktualisiert.

alter Kernel: 2.6.40.6-0
neuer Kernel: 2.6.41.4-1

Wenn ich mit dem alten Kernel boote, wird der Takt korrekt heruntergeregelt, cpuinfo_cur_freq zeigt dann auch 800 Mhz an, nicht jedoch wenn ich mit dem neuen Kernel boote. Wisst ihr, woran das liegen kann?

zyrusthc
05.01.12, 10:31
Scheinst nicht der einzigste zu sein der da Probleme hat was Frequenzen angeht.
https://bugzilla.redhat.com/show_bug.cgi?id=758755

Greeez Oli

Bayerfans04
05.01.12, 11:28
Danke für deine Antwort. Da bei dem Fall das Problem im Batteriebetrieb auftritt, habe ich gerade bei mir im Batteriebetrieb getestet:

Im Ruhemodus beim Batteriebetrieb läuft die CPU auf 1700 Mhz (scaling_cur_freq immer auf 800Mhz), im Netzbetrieb sind es 1600 Mhz.

Bei dem von dir geposteten Bug wurde ja auch der 2.6.41.4-1 Kernel genutzt. Oder könnte ein Bios Update das Problem beheben?

zyrusthc
05.01.12, 11:30
Wenn ein Bios Update verfügbar ist dann würde ich das auf jeden Fall einspielen.

Greeez Oli

Bayerfans04
05.01.12, 11:47
Habe nun die aktuelle Bios-Version drauf, aber leider keine Änderung.

Der Unterschied beim Batteriebetrieb entsteht sogar, wenn die Batterie zwar im Notebook ist, aber es trotzdem am Netz ist, also nicht im "reinen" Batteriebetrieb.