CPU wacht 50.000 (!) mal pro Sekunde auf

[ding280]

Hallo,

ich habe mir gerade eben aus den etch-backports kernel 2.6.22-4-686 installiert, um dank CONFIG_NO_HZ noch etwas Energie zu sparen. Leider passierte genau das Gegenteil, derzeit wacht die CPU so ca. 50.000 (!) mal pro Sekunde auf (sagt powertop). Mit Kernel 2.6.18, der standardmäßig bei etch dabei ist, waren das so ca. 200 mal. Woran könnte das liegen und was kann ich dagegen tun?

Vielleicht noch ein paar Worte zu meiner Hardware: Ich habe ein Samsung X20 mit Pentium M (Intel(R) Pentium(R) M processor 1.73GHz)

Grüße Tommy

[LessWire]

Nur mal eine Vermutung, vielleicht passt die Meßmethode von Powertop nicht mehr zum tickless kernel!?

vg, L.W.

[ding280]

Hallo,

aber auch der Stromverbrauch liegt bei ca. 5 - 10 Watt höher (aber auch laut powertop).

Grüße Tommy

[Spasswolf]

powertop liefert doch eine Liste mit den häufigsten Ursachen.

[ding280]

Hallo,

ja, das schon. Aber ist relativ identisch mit der bei Kernel 2.18. Und nur Aufgrund des Kernel-Wechsel muss dieser doch nicht 250 mal öfter in der Sekunde aufwachen. Oder täusche ich mich da?

Hier aber mal die Ausgabe von powertop

Code: Alles auswählen

Cn                 Verweildauer       P-States (Frequenzen)
C0 (Prozessor läuft)    (93,7%)         1,74 GHz     0,0%
C1                0,0ms ( 0,0%)         1333 MHz     0,0%
C2                0,0ms ( 6,3%)         1067 MHz     0,0%
C3                0,0ms ( 0,0%)          800 MHz   100,0%
C4                0,0ms ( 0,0%)

Aufwachen pro Sekunde : 45068,7 Intervall: 10,0s
Stromverbrauch (nach ACPI): 26,7W (1,0 Std.) (Langzeit: 29,0W, 0,9 Std.)

Häufigste Ursachen für das Aufwachen:
  19,9% ( 25,2)       firefox-bin : futex_wait (hrtimer_wakeup)
  16,2% ( 20,5)           knotify : schedule_timeout (process_timeout)
  14,4% ( 18,2)              Xorg : do_setitimer (it_real_fn)
   7,9% ( 10,0)     passkey-agent : schedule_timeout (process_timeout)
   7,9% ( 10,0)     S20sysfsutils : cpufreq_governor_dbs (delayed_work_timer_fn)
   5,5% (  6,9)       <interrupt> : PS/2 keyboard/mouse/touchpad
   3,9% (  5,0)            dhcdbd : schedule_timeout (process_timeout)
   3,1% (  3,9)   <kernel module> : usb_hcd_poll_rh_status (rh_timer_func)
   3,0% (  3,8)       <interrupt> : Intel ICH6 Modem, ipw2200
   2,4% (  3,0)   thunderbird-bin : futex_wait (hrtimer_wakeup)
   1,6% (  2,0)            python : schedule_timeout (process_timeout)
   1,5% (  1,9)           yakuake : schedule_timeout (process_timeout)
   1,2% (  1,5)            mysqld : schedule_timeout (process_timeout)
   1,2% (  1,5)     <kernel core> : queue_delayed_work_on (delayed_work_timer_fn)
   0,9% (  1,1)           klipper : schedule_timeout (process_timeout)
   0,8% (  1,0)           dirmngr : schedule_timeout (process_timeout)
   0,8% (  1,0)    NetworkManager : schedule_timeout (process_timeout)
   0,8% (  1,0)          kwrapper : do_nanosleep (hrtimer_wakeup)
   0,8% (  1,0)          ifconfig : b44_open (b44_timer)
   0,8% (  1,0)             artsd : do_setitimer (it_real_fn)
   0,6% (  0,8)       <interrupt> : ide0
   0,6% (  0,7)     <kernel core> : neigh_table_init_no_netlink (neigh_periodic_timer)
   0,6% (  0,7)       firefox-bin : schedule_timeout (process_timeout)
   0,4% (  0,5)          events/0 : ipw_gather_stats (delayed_work_timer_fn)
   0,4% (  0,5)        uml_switch : do_setitimer (it_real_fn)

Grüße Tommy

[armin]

Ich glaube letztens habe ich gerade in einem Kernel-Changelog gesehen, dass irgendein Bug beseitigt wurde durch den Powertop unglaublich große Werte angezeigt hat.
Eventuell ist also alles halbsowild...

EDIT: Wenn man die häufigsten Ursachen direkt zusammen addiert sieht man ja auch schön, dass die 50000 gar nicht passen können.

[ding280]

Hallo,

Wenn man die häufigsten Ursachen direkt zusammen addiert sieht man ja auch schön, dass die 50000 gar nicht passen können.

Da hast du recht. Aber trotzdem ist der Energieverbrauch deutlich höher, oder hängt das damit zusammen?

Grüße Tommy