Fragen zur Interrupt/schedulingverhalten in Jessie

[hinnack93]

Moin,

ich weiss nicht, ob dies Thema bei den Grundsatzfragen oder Kernelfragen richtig ist. Zunächst zu den Problemen, die ich in meinen System habe.

Der PC fungiert als Streaming-, File- und Webserver. Alle paar minuten brechen mir die streams zusammen, weil der cx23885 treiber nicht vom scheduler bedient wird. Die Meldungen im syslog lauten : cx23885_wakeup: 4 buffers handled (should be 1).
In Powertop gehen die Auslastung und Ereignisse um mehr als das fünffache der normalen werte hoch. Beim cx23885 von normal 5.3ms/s 100 ereignisse auf 300-400ms/s und 500 ereignisse. Alle anderen prozesse und interrupts sind ähnlich betroffen.

Durch ausschalten von sämtlichen powersave, speedstep und festpinnen der CPU auf 1.6GHZ hat sich das Verhalten gebessert, ist aber nicht verschwunden. Die oben genannten Werte sind diese Werte. Dasselbe verhalten tauscht auch auf einen anderen Mainboard auf.

Um mit den Deadline scheduler im kernel zu arbeiten fehlt mir das wissen. Welchen Ansatz zur weiteren Fehlersuche könnt ihr mir empfehlen?

[smutbert]

Um mit den Deadline scheduler im kernel zu arbeiten fehlt mir das wissen

Es ist nicht schwer den Scheduler zu wechseln. Ich habe elevator=deadline zu den Kernelparametern hinzugefügt um ihn zum default für alle Massenspeicher zu machen.
Es ist aber auch nicht weiter schwierig den scheduler eines Geräts anzuzeigen oder zu ändern, am Beispiel von /dev/sda in der Kommandozeile

Code: Alles auswählen

# cat /sys/class/block/sda/queue/scheduler 
noop deadline [cfq]
# echo deadline > /sys/class/block/sda/queue/scheduler
# cat /sys/class/block/sda/queue/scheduler 
noop [deadline] cfq

Automatisieren, sodass das beim Systemstart erledigt wird, kann man das zB mit den sysfsutils mit einer .conf-Datei unter /etc/sysfs.d mit einem Inhalt wie

Code: Alles auswählen

class/block/sda/queue/scheduler = deadline

[hinnack93]

danke smutbert,

das ist ja alles richtig, nur ist der cx23885 kein blockdevice sondern der Treiber der beiden DVBS karten. Die blockdevices sind da sehr unauffällig. Meinst du das die blockdevices solche verzögerungen im scheduler hervorrufen können?. Ins system einpflegen werde ich das trotzdem schonmal.

Die Warnung im Kernel git hat mir ein bisschen Angst gemacht.

+ Fiddling with these settings can result in an unpredictable or even unstable
+ system behavior. As for -rt (group) scheduling, it is assumed that root users
+ know what they're doing.
+

[smutbert]

Dass das der Treiber für eine Video- oder TV-karte ist, habe ich ergoogelt, aber du selbst hast die scheduler ins Spiel gebracht und mir wäre es neu, dass man auch für andere Datenlieferanten bzw. -senken als Blockgeräte einen Scheduler auswählen kann.

Die Idee Ist mir aber trotzdem nicht allzu widersinnig vorgekommen, weil ich selbst mit Festplatten (allerdings mit NCQ) mit deadline recht gute Erfahrungen gemacht habe, was die Reaktionsfreudigkeit des Systems angeht und da dachte ich es könnte auch dein Problem mildern — vielleicht geht der Gedanke angesichts der Tatsache, dass bei dir wahrscheinlich das Schreiben oder Lesen von Datenträgern keine große Rolle spielt, auch in die komplett falsche Richtung.


Ganz allgemein würde ich aber davon ausgehen, dass die "Reibungsverluste" umso größer sind je öfter die Daten vom TV/Videotreiber abgeholt werden müssen.
Ich weiß nicht ob das eine Option ist, aber ich würde daher eher den den Zwischenspeicher vor dem Streamen zu vergrößern, damit es nichts macht, dass sich bereits wie in deinem Beisipiel 4 Datenpakete angesammelt haben. Ev. läßt sich ja auch mit Optionen von der TV-Software oder dem Treiber die Größe der Datenpakete vergrößern.
(Ich stell mir das ganz analog zu Audio vor, wo man ja auch die Buffer und damit die Latenz vergrößert, wenn der Rechner nicht hinterherkommt und der Ton zu stottern beginnt.)

[hinnack93]

Ich denke das Problem liegt irgendwo bei der Interruptbearbeitung. In Powertop ist zu sehen, dass alle paar minuten die bearbeitungszeit und ereignisse/s um das fünffache steigt. Bei allen interrupts und prozessen. Dabei verhungern einige interrrupts und die buffer laufen über.

Zunächst habe ich mal die mpeg buffer in den DVBS karten(eigenes sram) aufs maximum erhöht.

Leider ist dies, falls es funktioniert, ein WA und keine Lösung.