[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [Wheezy/Sid] KWin und XOrg fressen CPU-Zeit



Am Sonntag, 31. Juli 2011 schrieb Peter Schütt:
> Hallo,
> 
> >> Wenn es ein Plasma-Applet ist, dann dürfte wahrscheinlich auch der
> >> Prozess plasma-desktop mit hoher CPU-Auslastung auftauchen, es sei
> >> denn das Plasma Applet generiert überwiegend Grafikauslastung, was
> >> ich nun auch eher unwahrscheinlich finde.
> > 
> > Der plasma-deskop Prozeß hat nur eine niedrige CPU-Auslastung
> > 
> >> Eine Möglichkeit wäre, mal ein Alt-F2 killall plasma-desktop zu
> >> machen, zu schauen, was passiert, dann mit Alt-F2 plasma-desktop
> >> die Plasma-Oberfläche wieder zu starten und Ausgabe von Top
> >> vergleichen.
> > 
> > Das ist ein Volltreffer.
> > Nach einem killall plasma-desktop gehen kwin und xorg auf 1-2 %
> > herunter.
> > 
> > Nach einem plasma-deskop & geht kwin auf 34 % und Xorg auf 17 %. Im
> > laufe der Stunden steigen sie dann immer weiter an, bis es auch auf
> > einem Quadcore spürbar wird.
> 
> Ich bin etwas weiter. Wenn ich KNemo abschalte, dann gehen die Prozente
> auf 1-2 % herunter. Wenn ich allerdings jetzt in KNode schreibe, dann
> gehen sie wieder auf 20-30% für KWin und XOrg hoch und wenn ich
> aufhöre, gehen sie wieder herunter.
> KNemo hat dauernd irgendetwas gemacht, was die CPU beschäftigt hat.

Naja, ich schau grad mal, wie es hier so ist, wenn ich auf die Mail 
antworte. Nun, X.org geht hier nicht über 5-12 % drüber, so wie es 
ausschaut. Akregator hat fast permanent 9% Auslastung, was fürs Nichtstun 
etwas arg viel ist. War nicht mal ein Artikel offen, wo evtl. das Adobe 
Flash Plugin hätte reinfunken können.

Kwin sehe ich bei der Auslastung mit 3-5%.

Ich hatte auch mal KNemo laufen und da ist mir so ein extremer Effekt nicht 
aufgefallen.

Auch wenn plasma-desktop bzw. genauer evtl. KNemo den Effekt auslöst, muss 
dies nicht die Ursache für den Effekt sein.

Also für reines Tippen finde ich 20-30% CPU-Auslastung für KWin und X.org 
zusammengenommen durchaus denkbar.Wenn ich die 5-10% für X.org und die 
3-5% für Kwin zusammen addiere, komme ich durchaus auch auf bis zu 17%. 
Allerdings sind das dann Peak-Werte. Oftmals sind die Werte niedriger.

Da wäre ein Protokoll via atop oder sysstat ganz sinnvoll.

Ich könnte KNemo natürlich auch nochmal testweise laufen lassen, wenn Du 
möchtest.

> Ist das denn richtig so, daß simples Schreiben die CPU-Last für XOrg
> und KWin hochtreibt? Wenn ja, dann wäre mein Problem gelöst.

Nunja, es kommt darauf an, wie stark der Treiber die GPU verwendet, um 
diese Operationen zu beschleunigen. Und ich vermute, dass es da bei der 
Anzeige von Text gewisse Grenzen gibt. Ich vermute mal, das ist aber 
gerraten, dass die Bitmaps der Zeichen noch die CPU aus den Vektorgrafiken 
erstellt. Allerdings gibt es da meines groben Wissens einen Cache für und 
daher dürfte das nach einer Weile schreiben auch nicht mehr so ins Gewicht 
fallen.

PS: Wenn ich in KMail scrolle, dann habe ich auch mal schnell sowas:

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                            
17207 root      20   0  351m  39m 5900 S   23  0.5  47:29.10 Xorg                               
 2743 martin    20   0  954m 218m  38m S   17  2.8   3:07.48 kmail                              
17342 martin    20   0  614m  36m  29m S    7  0.5  19:32.15 kwin  

Ich würde mir also davon ausgehen, dass sich die von Dir genannten Werte - 
wenn KNemo nicht läuft - noch im Rahmen halten.

Das ist dann im Detail denke ich eher ein Feld für X.org-, Grafik-Treiber 
und Compositor-Entwickler. Möglicherweise gibts das irgendwann mal, dass 
die GPU die Zeichen als Texturen auf den Bildschirm beamt ;). Ob das aber 
wirklich effizienter ist...

Und dann wäre das noch mit der Anzahl der CPUs/Kerne in Relation zu 
setzen. Und wie mir gerade einfällt ganz wichtig: Die aktuelle Frequenz 
der CPU und der Idle-Stats:

Hier läuft die CPU beim Tippen laut Powertop nämlich mit über 35-50% bei 
800 MHz und verwendet ca. 3-8% im Turbo-Mode (irgendwo überhalb 2,5 GHz) - 
hä? für wirklich schnelle Zeichen-Anzeige? ;)

Und ja, das addiert sich nicht mal auf die 100%. Wohl weil die CPU 
insgesamt ca. 91,3% im C2-Zustand idlet.

Also wenn ich den den CPU-Governor mal auf Performance stelle, mal sehen, 
was dann in top noch übrig bleibt.

merkaba:~> grep . /sys/devices/system/cpu/cpu?/cpufreq/scaling_governor
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:ondemand
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:ondemand
/sys/devices/system/cpu/cpu2/cpufreq/scaling_governor:ondemand
/sys/devices/system/cpu/cpu3/cpufreq/scaling_governor:ondemand

merkaba:~> cpufreq-set -g performance                                  
merkaba:~> grep . /sys/devices/system/cpu/cpu?/cpufreq/scaling_governor
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:performance
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:ondemand
/sys/devices/system/cpu/cpu2/cpufreq/scaling_governor:ondemand
/sys/devices/system/cpu/cpu3/cpufreq/scaling_governor:ondemand
merkaba:~> cpufreq-set -c 1 -g performance                             
merkaba:~> cpufreq-set -c 2 -g performance
merkaba:~> cpufreq-set -c 3 -g performance
merkaba:~> grep . /sys/devices/system/cpu/cpu?/cpufreq/scaling_governor
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:performance
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:performance
/sys/devices/system/cpu/cpu2/cpufreq/scaling_governor:performance
/sys/devices/system/cpu/cpu3/cpufreq/scaling_governor:performance

Sodele.... mal sehen, was jetzt beim Tippen noch übrig bleibt. Okay, X.org 
ist zwischen 2und 5% so wie es aussieht und kwin bei ca. 2-3%. Bleibt das 
auch in etwa so? Lorem Ipso Tut Anch Amun. Jow, so in etwa.

Sodele, jetzt wieder Energie sparen:

merkaba:~> cpufreq-set -c 0-3 -g ondemand                              
merkaba:~> grep . /sys/devices/system/cpu/cpu?/cpufreq/scaling_governor
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:ondemand
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:performance
/sys/devices/system/cpu/cpu2/cpufreq/scaling_governor:performance
/sys/devices/system/cpu/cpu3/cpufreq/scaling_governor:performance

*grr*

merkaba:~> cpufreq-set -c 0,1,2,3 -g ondemand                        
merkaba:~> grep . /sys/devices/system/cpu/cpu?/cpufreq/scaling_governor
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:performance
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:ondemand
/sys/devices/system/cpu/cpu2/cpufreq/scaling_governor:performance
/sys/devices/system/cpu/cpu3/cpufreq/scaling_governor:performance

Also dann doch:

merkaba:~> for CPU in 0 1 2 3; do cpufreq-set -c $CPU -g ondemand ; done
merkaba:~> grep . /sys/devices/system/cpu/cpu?/cpufreq/scaling_governor 
/sys/devices/system/cpu/cpu0/cpufreq/scaling_governor:ondemand
/sys/devices/system/cpu/cpu1/cpufreq/scaling_governor:ondemand
/sys/devices/system/cpu/cpu2/cpufreq/scaling_governor:ondemand
/sys/devices/system/cpu/cpu3/cpufreq/scaling_governor:ondemand

So ich denke, damit hab ich einen etwas differenzierteren Blick auf die 
Situation geboten und Ansätze, das bei Bedarf näher zu untersuchen.

-- 
Martin 'Helios' Steigerwald - http://www.Lichtvoll.de
GPG: 03B0 0D6C 0040 0710 4AFA  B82F 991B EAAC A599 84C7


Reply to: