Linux Desktop flinker mit Prozessorgruppen.

@all

Unter Ubuntu 10.04 (Lucid) gibt es ein Problem mit der cgroup Implementation! Siehe hier.

Es ist egal welcher Implementation man folgt, meiner Beschreibung von weiter oben mit den statischen Prozessdosen oder den modularen Prozessgruppen wie in diesem Post verlinkt beschrieben. In beiden Fällen wird fälschlicherweise der Prozess [kthreadd] in eine Standardgruppe, default oder sysdefault, verschoben, der kein RealTime Scheduler zugewiesen ist. Das führt effektiv dazu das sich keine Kernel Module mehr automatisiert mit "rmmod" entfernen lassen, der Prozess wartet auf dann Feedback das er niemals bekommt.

Im Falle eines ungeplanten VDR Neustarts durch den Watchdog, führt das dann dazu, das die DVB Module nicht entfernt werden können und der Watchdog quasi ins Leere läuft.

Das ist sehr ärgerlich, es gibt leider keine Lösung für Lucid :weinen, bei Maverick gibt es das Problem nicht.

Regards
fnu

Zitat

Original von Morone
Doch, Upgrade auf Maverick

Ja und nein, nur ein glücklicher Umstand in Systemkonfiguration bei Maverick führt dazu, das [ktreadd] nicht nach sysdefault verschoben wird. Es ist also nicht gesichert das das auf ewig so bleibt, weil der eigentliche Move nicht verhindert wird.

Ich teste das gerade mit Maverick, aber was schon auffällt, Maverick hat initial wesentlich mehr Fehler die es nachzulesen gibt als Lucid, obwohl ja eigentlich keine so großen Umbauten stattgefunden haben sollen ...

Regards
fnu

speefak

Freund, sag mal Du hast schon gelesen, das es hier weder um SysV Init noch um Upstart geht?

Es geht um die Gruppierung von Prozessen um eine geänderte Auslastung bis hin zu Priorisierung bei für das System wichtigen Prozessen zu erreichen. Bei einem VDR mit Software basierter Ausgabe z.B. eben um das wichtige Videoausgabe Frontend.

Wenn Du nichts zum Thema beizutragen hast, würde ich vorschlagen Du schaust Dir das Depeche Mode Konzert von gestern an oder geh und prügel auf den armen "det" ein ...

Nochmal der Hinweis auf die Warnung zur cgroups-rmmod Problematik in diesem Post.

Regards
fnu

speefak

Vmtl. habe ich überreagiert, entschuldige vielmals. Ändert aber nix an der Tatsache, das es hier nicht um SysV-Init & Upstart ging.

@all

Es gibt doch ein Workaround siehe hier. Der Parameter "cpu.rt_runtime_us" muß einen Wert erhalten, z.B. "950000" was offensichtlich der Standard-Wert für Prozesse mit RealTime Priorität ist. Ein guter Platz unter Lucid und evtl. Maverick ist die "/etc/rc.local":

echo 950000 > /cgroups/cpu/sysdefault/cpu.rt_runtime_us
...
oder je nach Konfiguration
...
echo 950000 > /cgroups/cpu/default/cpu.rt_runtime_us

Schön, dann kann ich das doch auf meinem Single Core VDR umsetzen und diese kleinen kleinen Wackler sind wieder weg und das OSD fluppt wieder richtig schnell anstatt nur schnell ...

Regards
fnu

@all

Mal ein Update zu dem Thema, das besonders alle Nutzer von Ubuntu Lucid 10.04.x (Lucid Lynx) mit aktuellen Kernel interessieren wird. Das ist vmtl. die Masse der VDR Nutzer bedingt durch die entsprechende Basis yaVDR, easyVDR 0.9 oder auch freevdr.

Aufgrund dieses Threads habe ich mich noch mal mit meiner Userspace Implementation zu cgroups auseinander gesetzt, konkret, ich habe sie entfernt. Bei der zufälligen Durchsicht von syslog & dmesg ist mir folgendes aufgefallen:

#/> dmesg |grep cgroup
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] allocated 20971520 bytes of page_cgroup
[    0.000000] please try 'cgroup_disable=memory' option if you don't want memory cgroups
[    0.005121] Initializing cgroup subsys ns
[    0.005126] Initializing cgroup subsys cpuacct
[    0.005131] Initializing cgroup subsys memory
[    0.005139] Initializing cgroup subsys devices
[    0.005141] Initializing cgroup subsys freezer
[    0.005144] Initializing cgroup subsys net_cls

Ich nutze den letzten Kernelstand von Lucid 2.6.32-28. Diese Meldung bedeuten, das der cgroup Wunderpatch Einzug in die letzten Kernel Aktualisierung für die Version 2.6.32 von Ubuntu 10.04.x (Lucid Lynx) gehalten hat.

Ohne es zu merken hatte ich damit 2 cgroup Implementationen auf einem VDR, Kernel & Userspace, was vmtl. nicht so gut für's System sein dürfte ...

Mit diesen Änderungen im Kernel von Lucid ist auch keine Userspace Umsetzung mehr notwendig und damit auch der o.a. Workaround obsolete.

Regards
fnu