Ich verfolge Linux 0.11 https://mirrors.edge.kernel.org/pub / linux / kernel / Historic / old-version /

Ich sehe, dass es viele Schedule () -Aufrufe an verschiedenen Orten gibt, nicht nur den in do_timer ().

Einige Fragen hier:

  1. do_timer () (@ sched.c) wird jedes Mal aufgerufen, wenn das Timer-Timeout auftritt? Dieser Timer basiert auf einem x86-Interrupt-Aufruf?

  2. Kann ich sagen, dass es eine Art Preempting gibt, da es außerhalb von do_timer () viele Schedule () -Aufrufe gibt? oder was ist der Zweck?

1
Mark 18 Jän. 2019 im 11:00

3 Antworten

Beste Antwort
  1. Der Status einiger Aufgaben hat sich geändert und muss im Zeitplan () aktualisiert werden.
  2. Einige Aufgaben funktionieren und es gibt noch viel Arbeit. Planen Sie (), um das Gleichgewicht zu halten.
1
Mark 22 Jän. 2019 im 03:16

Jede Operation, die Aufrufe von Schedule () blockiert, um die Kontrolle zu gewährleisten.

1
stark 18 Jän. 2019 im 18:14

Kann ich sagen, dass es eine Art Preempting gibt, da es außerhalb von do_timer () viele Schedule () -Aufrufe gibt? oder was ist der Zweck?

Für ein echtes Betriebssystem; Die meisten Taskwechsel erfolgen, weil eine Task das Warten auf etwas blockiert (Benutzereingabe, Netzwerkpaket, Festplatten-E / A usw.) oder eine Task entsperrt, weil etwas passiert ist, auf das sie gewartet hat (und die nicht blockierte Task eine höhere Priorität hat und die aktuell ausgeführte niedrigere Priorität verhindert Aufgabe).

Die ganze Sache "Taskwechsel durch Timer-IRQ verursacht" ist meist nur ein Fallback zum Schutz vor böswilligen CPU-Schweinen (Denial-of-Service-Angriffe); und für normale Software unter normalen Bedingungen können Sie sie deaktivieren (schedule() aus dem Timer-IRQ-Handler löschen), und niemand würde es bemerken oder sich darum kümmern. Hinweis: Einige Leute werden sagen, dass dies auch für "nicht böswillige" CPU-gebundene Aufgaben gilt, aber CPU-gebundene Aufgaben sind relativ selten und (ohne Berücksichtigung der Tatsache, dass der Linux-Scheduler noch nie für Aufgabenprioritäten geeignet war) für CPU-gebundene Aufgaben Es ist besser, sich auf ein effektives System von Aufgabenprioritäten zu verlassen (z. B. den CPU-gebundenen Aufgaben eine niedrige Priorität zuzuweisen, damit fast alles sie verhindert).

Beachten Sie auch, dass verschiedene Kurse zur OS-Theorie mit Konzepten beginnen, die so einfach sind, dass sie in der Praxis nie tatsächlich vorkommen. Dies ist fast immer ein reiner Round-Robin-Scheduler mit Aufgaben, die niemals blockiert werden (häufig mit "Hey, wir können die Zukunft genau vorhersagen und" Sie müssen genau wissen, wie lange jede Aufgabe für "Unsinn" ausgeführt wird. Dies ist meistens als erster Schritt in Ordnung (in einem "Lernen, wie man läuft, bevor Sie laufen"), saugt aber große salzige Hundebälle, wenn es nicht realistischer und komplexer folgt Konzepte (bessere Planungsalgorithmen, Aufgabenprioritäten, mehrere simultane Planungsalgorithmen / "Scheduler-Richtlinien", Multi-CPU, interaktive / latenzempfindliche Aufgaben, ..), weil der Schüler / das Opfer nur noch Fehlinformationen hat (z. auftretende "alle Aufgabenwechsel werden durch Timer-IRQ verursacht" Missverständnis).

do_timer () (@ sched.c) wird jedes Mal aufgerufen, wenn das Timer-Timeout auftritt? Dieser Timer basiert auf einem x86-Interrupt-Aufruf?

Ich vermute, dass der Timer der IRQ des rohen PIT-Chips war (da Linux Version 0.11 "absolute Anfängerentwickler ohne die Absicht, ihn portabel zu machen" war, historische Erinnerungsstücke, bevor Tausende von Freiwilligen die Hälfte der schlimmsten Teile reparierten).

Vergessen Sie auch nicht, dass der Scheduler Zeit für zwei verschiedene Dinge verwendet - die Sache "Aktuelle Aufgabe hat zu viel CPU-Zeit verbraucht", die fast nie wichtig ist, und herauszufinden, wann Aufgaben blockiert sind / schlafen (z. B. weil sie {{X0 aufgerufen haben) }}) sollte entsperren / aufwachen. Das do_timer() kann für eines dieser Dinge und für beide sein (ich weiß es nicht, ohne es anzusehen).

0
Brendan 22 Jän. 2019 im 07:11