Linux Desktop flinker mit Prozessorgruppen.

@all

IMHO definitiv ein beachtenswertes Thema für VDPAU VDR's:

• Linux: Flinker Desktop unter Last
• Kernel-Log: Flinker mit Prozessorgruppen

[07.01.2011] Die Änderung wirken sich nur bei hoher Belastung aus und scheinen die größten Auswirkungen auf Single-Core Installationen zu haben:

• Änderung vorallem für SingleCore Installationen sinnvoll!

[14.01.2011] Interessante deutschsprachige Einführung:

• [URL=http://www.pro-linux.de/artikel/2/1464/1,einfuehrung-in-control-groups.html]Resourcen-Verwaltung mit Control Groups (pro-linux.de)[/URL]
• Resource Management: Control Groups - Linux legt Prozesse in Ketten

[15.01.2011] Auf meinen Wunsch hin nach "VDR Grundlagen" verschoben. Vielen Dank an skiller2k1!

Da sich die Wirkung bei hochbelasteten Systemen deutlich verstärkt, könnte ich mir vorstellen, das eine Umsetzung auf den S100 bzw. SMT7202S Distro's, das Verhalten der Frontends stark verbessern würde. Die CPU dieser kleinen Boxen rennt ja doch eigentlich immer bei 70-80% ...

Gruß
Frank

Zitat

Original von Morone
Ich wuerde mal behaupten , es bringt fuer nen vdpau gestuetzten VDR
so gut wie rein garnix, denn die CPU hat da nun wirklich am wenigsten zu tun.
Ist ja auch Sinn der Sache.

So etwas kann man IMHO nur behaupten, wenn man sich mit den Zusammenhängen nicht wirklich auseinander gesetzt hat.

Die CPU ist definitiv wichtig bei VDPAU (= grafischer Desktop!) und sie muß etwas tun. Der Nvidia-Treiber sorgt mit der Grafikkarte nur für die Zuarbeit zur CPU und nicht andersherum. Es ist ein Ammenmärchen, wenn behauptet wird alles läuft auf der Grafikkarte ab. CPU, Memory und Grafikkarte sind bei VDPAU quasi eine Einheit, schwächelt ein Teil, schwächelt alles.

Beim Schnitt oder bei noad/markad geht die CPU Auslastung noch stärker nach oben. Und was zur Hölle spricht dagegen auch nur 1-2% Gewinn mitzunehmen, wenn es nichts kostet.

Das Thema ist für "embedded" VDRs auf Basis von FF, DXR3, Reelhd und zukünftig auch FF-HD bei reinem VDR Betrieb uninteressant. Sollten aber Server-Services insbesondere Remuxing Themen dazu kommen, sieht die Lage schon wieder ganz anders aus.

Regards
fnu

@all

Für die Prozessgruppen muss man weder den Kernel patchen, noch auf einen gepatchten Kernel warten. Die von Lennart Poettering hier favorisierte Lösung für den Userspace, auch gegenüber Linux Torvalds, läßt sich auch mit älteren Kernel-Versionen umsetzen:

• Stefan Lesicnik: cgroup user space speed patch

Ohne es für alle ausprobiert zu haben, vermute ich aber, der Weg läßt sich auf fast allen aktuellen Debian-basierten System umsetzen. Zumindest unter Ubuntu 10.04 (lucid) funktioniert die Umsetzung wie beschrieben. Was es aber im realen Leben bringt, wird die Zeit zeigen.

Gruß
Frank

@all

Nachdem der Bericht auf heise-open explizit auf Verbesserung bei Single-Core Installationen hinwies, habe ich das mal ausprobiert und wieder meinen Sempron 140 in den Haupt-VDR eingebaut. Den habe ich sowieso hier rumliegen und bei meinem Exemplar läßt sich auch der zweite Kern eh nicht freischalten.

Während die Verbesserungen mit cgroups beim seither verbauten Athlon X2 subjektiv eher homöopatisch waren, xine-ui reagierte subjektiv deutlich flinker, sind die Verbesserungen beim Sempron 140 (Single-Core) deutlich zu spüren.

Ich habe die CPU ja eigentlich seit Sommer 2009 am Start und das größte Problem war immer das parallele Schneiden von Aufnahmen, das führte in der Regel zu Aussetzern bei der Bild-Ausgabe von HD Sendern. Die Aussetzer waren je nach Patch-Level mal größer mal kleiner und es war eigentlich undenkbar parallel weitere Aufnahme fürs Schneiden vorzubereiten oder gar eine HD Aufnahme anzuschauen. Die Lösung war dann eben eine X2 CPU.

Mit der o.a. Umsetzung der cgroups hat sich das schlagartig geändert. Die sorgt nämlich dafür, das xine-ui@Xorg vom restlichen System separiert behandelt wird und trotz Schnitt immer noch ausreichend CPU Zeit für die Bild-/OSD-ausgabe erhält. Der Schnitt einer HD Aufnahme, das parallele Anschauen einer 1080i Aufnahme und das Aufrufen eines der text2skin-Skins sorgen lt. systeminfo für 100% CPU Auslastung, der VDR ist aber normal ohne Verzögerungen bedienbar, es verhält sich IMHO wie ein Dual-Core System, sehr cool. Und natürlich kann ich jetzt auch parallel andere Aufnahmen wieder zum Schnitt vorbereiten ...

[EDIT]

Evtl. wären diese cgroups auch was für die schwachbrüstigen Single-Core Installation auf S100 & SMT7020S etc.?

[/EDIT]

Gruß
Frank

PS.: Einen Punkt möchte ich noch erwähnen, ich finde das das Schneiden mit viel zu hoher Priorität im VDR läuft. Das Schneiden belastet das System IMHO höher als nötig, es wäre doch egal ob der Schnitt in 1,2,3,4 Minuten fertig wäre. Und ja, das hatte ich "kls" schon mal geschrieben ...

herrlado

O.a. Link erläutert die Umsetzung in Debian/Ubuntu Systemen, inwieweit sich das von gentoo unterscheidet weiß ich nicht. Da möchte ich Dich bitten selbst mal zu google'n.

Lt. o.a. Link zu einer Aussage von Lennart Poettering, geht es tatsächlich nur um zwei "mounts" für den cgroups "Service". Und wenn ich nachschaue, kann ich da auch keinen Scheduler-Typ konfigurieren.

Du hast die angegeben Links schon mal angeschaut, oder? Evtl. einfach ein "emerge cgroups-bin" und die gleichen Anpassungen wie für Ubuntu ... ?

Gruß
Frank

herrlado

Ach jetzt verstehe ich Deine Frage, aber warum stellst Du sie nicht gleich so ...

Also, es gibt 2 Wege (!), einmal einen Kernel-Patch, der wohl in 2.6.38 einfliessen wird, der dafür sorgt das die cgroups gebildet werden.

Das gleiche Verhalten kann man wohl schon viel länger im User-Space, also per Systemkonfiguration bewirken, ohne Patch und ohne neue Kernel-Version. Meine letzten Posts zielten auf diese User-Space Anpassung ab, Du benötigst keinen super-aktuellen Kernel, läuft bei Ubuntu wohl schon seit 9.04.

Die Herren Poettering und Torvalds sind sich nicht ganz einig, welcher Weg besser ist, obwohl beide zum gleichen Ziel führen ...

Gruß
Frank