Login
Newsletter
Werbung

Thema: SCHED_DEADLINE in den Kernel aufgenommen

20 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
0
Von maxxx am Mi, 22. Januar 2014 um 14:06 #

Und was kann der jetzt besser, als die anderen?

[
| Versenden | Drucken ]
0
Von Pffft... am Mi, 22. Januar 2014 um 14:12 #

die Software und die Distributionen müssen diese Mechanismen auch mal nutzen. Zum Beispiel würde es sich ja anbieten, AV-Applikationen (auf dem gemeinen Desktop wohl das einzige, was von Echtzeit profitiert) in einen GUI- und einen Hintergrundprozess aufzuspalten, wobei letzterer dann mit Echtzeit läuft. Man könnte mit der lahmsten Hardware zumindest ruckelfrei Musik und Videos abspielen. So hat das schon vor 15 Jahren mit nur wenig Gefummel und den simplen Programmen und der Hardware damals geklappt.

Und heute? Keine Chance, gigantische AV-Stacks, in denen der normale Anwender niemals durchschaut, welche Komponente nun für das Ruckeln verantwortlich ist. Den ganzen Browser wollte ich auch nicht unbedingt mit SCHED_FIFO laufen lassen, dafür ist mir das Ding dann doch zu fett. Glücklich, wer eine Audio-Distribution verwendet, da ist zumindest dieser Teil besser vorkonfiguriert. Dafür ist dann irgendwas anderes kacke.

[
| Versenden | Drucken ]
  • 0
    Von BT90 am Mi, 22. Januar 2014 um 19:28 #

    SCHED_FIFO gehört ins Schulbuch und nicht auf ein System,das man wirklich benutzen will.

    [
    | Versenden | Drucken ]
    • 0
      Von Pffft... am Mi, 22. Januar 2014 um 20:51 #

      Völliger Unsinn, QNX hat z.B. nichts anderes als SCHED_FIFO. Da lernt man dann auch gleich, ohne Busy-Loops und Deadlocks zu programmieren.

      [
      | Versenden | Drucken ]
      • 0
        Von chrm am Do, 23. Januar 2014 um 11:33 #

        Damit bestätigst Du genau die Aussage Deines Vorposters.

        [
        | Versenden | Drucken ]
        • 0
          Von Pffft... am Do, 23. Januar 2014 um 18:00 #

          Nö. QNX-Systeme funktionieren hervorragend in Industriesteuerungen und als Autoelektronik. Nur gibt es für Linux halt mehr Leute, die sich damit auskennen, von daher ist QNX zu teuer geworden.

          [
          | Versenden | Drucken ]
    0
    Von Herzlos am Mi, 22. Januar 2014 um 19:32 #

    AV-Applikationen (auf dem gemeinen Desktop wohl das einzige, was von Echtzeit profitiert)

    Es macht auch Sinn, wenn auch Computerspiele schnellstmöglich auf die Eingaben des Nutzers reagieren können und nicht nur Audio & Video-Applikationen.


    Meiner Erfahrung nach hakte es bei Egoshootern immer fühlbar, so dass ich z.B. Doom 3 trotz brauchbarer Frameraten lieber unter Windows durchgespielt habe. Mit einem anderen Scheduler kann so etwas natürlich wesentlich besser laufen.

    Man könnte mit der lahmsten Hardware zumindest ruckelfrei Musik und Videos abspielen. So hat das schon vor 15 Jahren mit nur wenig Gefummel und den simplen Programmen und der Hardware damals geklappt.
    BeOS ;)

    [
    | Versenden | Drucken ]
    • 0
      Von Pffft... am Mi, 22. Januar 2014 um 20:47 #

      Linux anno 1998. Damals war das kein Problem, weil die zeitkrtische Anwendung eben mpg123 war oder der Realplayer (spuck!) und das ganze direkt auf /dev/dsp und /dev/video ausgab. Heutzutage sind einerseits die Ansprüche etwas gestiegen, es soll direkt aus dem Browser gehen - ist ja nach 15 Jahren auch nicht zuviel verlangt -, andererseits sitzt jetzt noch ein Sound-Framework des Desktops und womöglich noch ein Soundserver dazwischen der irgendwelche supertollen Dinge macht, die 99% der Anwender nicht benötigen.

      Da wäre es toll, wenn die Desktop-Distributionen eben nicht auf Featuritis setzen würden, sondern darauf, was wirklich wichtig ist: Ruckelfrei, unabhägig ob die Hardware nun von 2004 stammt oder von 2014. Es ging wie gesagt bereits 1998.

      [
      | Versenden | Drucken ]
      • 0
        Von Herzlos am Mi, 22. Januar 2014 um 23:18 #

        Linux anno 1998. Damals war das kein Problem,

        Doch, als Unix like Multiuser- und Multitastkingbetriebssystem musste Linux schon damals mehrere Programme "gleichzeitig" laufen lassen und war auch schon damals für Realtimeanwendungen nicht besonders gut geeignet bzw. optimiert, der Schwerpunkt der Entwicklung lag zu dem Zeitpunkt immer noch auf Serveraufgaben und Multimedia stand da eher ganz hinten an.
        Die Prozess- und auch Threadverwaltung war schon damals ein Thema und daran änderte auch der direkte Zugriff auf /dev/dsp und /dev/video nicht viel.

        BeOS war zu dem Zeitpunkt, als es neu war, dagegen eine Wucht.
        Das es sich nicht gegen Windows behaupten konnte und meiner Meinung nach auch die Multiuserfähigkeit fehlte, ist ein anderes Thema, aber was zeitkritische Multimediaanwendungen anbelangt, dafür war es wie geschaffen.

        womöglich noch ein Soundserver dazwischen der irgendwelche supertollen Dinge macht, die 99% der Anwender nicht benötigen.

        Der Soundserver sorgt dafür, dass der Sound von verschiedenen Anwendungen über ein einziges Sounddevice quasi gleichzeitig ausgegeben werden kann.
        Ohne Soundserver würde die eine Anwendung das Sounddevice belegen, ehe die andere Anwendung dieses benutzen kann.
        Insofern brauchen so etwas 99 % der Anwender.
        Die einzige Ausnahme davon sind bestenfalls diejenigen, die eine Soundkarte eingebaut haben, die Hardwaremixing beherrscht, aber da ist die Anzahl der Sounds die gleichzeitig zusammengemischt werden können auch irgendwann limitiert.

        [
        | Versenden | Drucken ]
        • 0
          Von Pffft... am Do, 23. Januar 2014 um 00:36 #

          Ohne Soundserver würde die eine Anwendung das Sounddevice belegen, ehe die andere Anwendung dieses benutzen kann.
          Das kann alsa bereits innerhalb des Treibers - ohne spezielle Hardware. Dazu benötigt man keinen Soundserver, den braucht man nur, falls man Netzwerksound haben will und/oder Quellen ständig umstöpseln.

          [
          | Versenden | Drucken ]
    0
    Von Der Jupp am Mi, 22. Januar 2014 um 20:03 #

    ????

    Hä?

    Hier geht es um den Prozess-Scheduler des Kernels. Da kannst pro Kernel genau einen haben! Unterschiedliche Scheduler pro Prozess??? Da müsstest du für jeden unterschiedlichen Scheduler schon eine eigene VM aufmachen...

    Es gibt noch I/O-Scheduler. Dort gibt es übrigens den Deadline schon sehr viel länger. Aber auch den kannst du nur einmal pro Blockdevice haben.

    Und ja, das haben die guten Distris auch implementiert, z.B. über tuned.

    Der Jupp

    [
    | Versenden | Drucken ]
    • 1
      Von Pffft... am Mi, 22. Januar 2014 um 20:40 #

      Falsch. man sched_setscheduler.

      Man kann je Thread und jederzeit im Programmlauf den für den Prozess zuständigen Scheduling-Mechanismus umschalten, z.B. um einen zeitkritischen Teil einer Anwendung in Echtzeit ablaufen zu lassen, den Rest dann aber wieder in SCHED_OTHER.

      [
      | Versenden | Drucken ]
0
Von Herzlos am Mi, 22. Januar 2014 um 19:27 #

Gibt es eine Möglichkeit bei laufendem System herauszufinden, welcher Scheduler im Einsatz ist?
Also kann man das irgendwie auslesen?

Von den Distributionen bekommt man in der Regel ja fertige Binarys
und spontan fällt mir nur ein, in die Kernelkonfiguration mit der das Binary erstellt wurde zu schauen, aber vielleicht gibt es dafür auch eine bessere Möglichkeit.

[
| Versenden | Drucken ]
  • 0
    Von Pffft... am Mi, 22. Januar 2014 um 21:15 #

    Du hast in aktuellen Kerneln immer den CFQ-Scheduler und die meisten Prozesse laufen als "SCHED_OTHER" (dynamische Priorität mit nice).

    [
    | Versenden | Drucken ]
    • 0
      Von Herzlos am Mi, 22. Januar 2014 um 23:21 #

      Und was ist mit SCHED_FIFO (Realtime First-in-first-out) und SCHED_RR (Realtime Round-Robin) wie der Artikel suggeriert?

      [
      | Versenden | Drucken ]
      • 1
        Von hjb am Mi, 22. Januar 2014 um 23:51 #

        Es gibt nur einen Scheduler. Anders als bei I/O-Schedulern, die dynamisch ersetzt werden können, hat Linus immer nur einen Scheduler im System toleriert. Andere Scheduler existieren allenfalls als externe Patches.

        SCHED_DEADLINE ist daher kein neuer Scheduler, sondern eine Erweiterung. Jeder Prozess kann in genau einer Scheduler-Klasse sein, und die Klassen werden vom Scheduler unterschiedlich gehandhabt. Prozesse können zwischen den Klassen wechseln, was aber teilweise nur von root ausgeführt werden kann.

        [
        | Versenden | Drucken ]
        • 0
          Von Herzlos am Do, 23. Januar 2014 um 01:55 #

          Es gibt nur einen Scheduler. Anders als bei I/O-Schedulern, die dynamisch ersetzt werden können, hat Linus immer nur einen Scheduler im System toleriert. Andere Scheduler existieren allenfalls als externe Patches.

          Das nur einer laufen kann ist mir klar, siehe mein erstes Posting.
          Sonst hätte ich ja wohl kaum das mit dem Kernelconfig auslesen erwähnt.


          Meine Frage ist allerdings, ob ich zur Laufzeit auslesen kann, welcher Scheduler reinkompiliert oder eben welche Erweiterung mitkompiliert wurde. Diese Frage wurde hier noch nicht beantwortet.

          [
          | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung