{"id":32730,"date":"2019-10-31T21:48:36","date_gmt":"2019-10-31T18:48:36","guid":{"rendered":"https:\/\/prohoster.info\/blog\/operating-systems-three-easy-pieces-part-5-planirovanie-multi-level-feedback-queue-perevod\/"},"modified":"2021-02-08T11:40:35","modified_gmt":"2021-02-08T09:40:35","slug":"operating-systems-three-easy-pieces-part-5-planirovanie-multi-level-feedback-queue-perevod","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/operating-systems-three-easy-pieces-part-5-planirovanie-multi-level-feedback-queue-perevod","title":{"rendered":"Betriebssysteme: Drei einfache Teile. Teil 5: Planung: Multi-Level-Feedback-Warteschlange (\u00dcbersetzung)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<h1>Einf\u00fchrung in Betriebssysteme<\/h1>\n<p>Hallo, Habr! Ich m\u00f6chte euch eine Serie von \u00dcbersetzungen einer interessanten Literatur vorstellen \u2014 OSTEP. In diesem Material wird die Funktionsweise von unix\u00e4hnlichen Betriebssystemen recht tiefgehend behandelt, insbesondere die Arbeit mit Prozessen, verschiedenen Planern, Speicher und anderen \u00e4hnlichen Komponenten, die ein modernes Betriebssystem ausmachen. Das Original aller Materialien k\u00f6nnt ihr hier ansehen <noindex><a rel=\"nofollow\" href=\"http:\/\/pages.cs.wisc.edu\/~remzi\/OSTEP\/\">hier<\/a><\/noindex>. Bitte beachtet, dass die \u00dcbersetzung nicht professionell (recht frei) durchgef\u00fchrt wurde, aber ich hoffe, dass ich die allgemeine Bedeutung erhalten habe.<\/p>\n<p>Die Laborarbeiten zu diesem Thema findet ihr hier:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"http:\/\/pages.cs.wisc.edu\/~remzi\/OSTEP\/Homework\/homework.html\">Original<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/remzi-arpacidusseau\/ostep-code\">Original<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/bykvaadm\/OS\/tree\/master\/ostep\">meine pers\u00f6nliche Anpassung<\/a><\/noindex><\/li>\n<\/ul>\n<p>Weitere Teile:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/446340\/\">Teil 1: Einf\u00fchrung<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/446866\/\">Teil 2: Abstraktion: Prozess<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/447182\/\">Teil 3: Einf\u00fchrung in die API von Prozessen<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/449026\/\">Teil 4: Einf\u00fchrung in den Planer<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/450116\/\">Teil 5: MLFQ-Planer<\/a><\/noindex><\/li>\n<\/ul>\n<p>Ihr k\u00f6nnt auch mal auf meinen Kanal in <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/bykvaadm\">Telegram<\/a><\/noindex> =)<br \/>\n<noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h2>Planung: Multi-Level Feedback Queue<\/h2>\n<p>In dieser Vorlesung werden wir die Herausforderungen der Entwicklung eines der bekanntesten Ans\u00e4tze zur<br \/>\nPlanung besprechen, der als <b>Multi-Level Feedback Queue<\/b> (MLFQ) bezeichnet wird. Der MLFQ-Planer wurde erstmals 1962 von Fernando J. Corbat\u00f3 im System beschrieben, das<br \/>\nCompatible Time-Sharing System (CTSS). Diese Arbeiten (einschlie\u00dflich der sp\u00e4teren Arbeiten an<br \/>\nMultics) wurden sp\u00e4ter f\u00fcr den Turing Award nominiert. Der Scheduler wurde<br \/>\nanschlie\u00dfend verbessert und nahm eine Form an, die man bereits in<br \/>\neinigen modernen Systemen finden kann.<\/p>\n<p>Der MLFQ-Algorithmus versucht, zwei grundlegende \u00fcberlappend Probleme zu l\u00f6sen.<br \/>\n<b>Erstens<\/b>, versucht er, die Durchlaufzeit zu optimieren, die, wie wir in der vorherigen Vorlesung behandelt haben, durch das Starten der k\u00fcrzesten Aufgaben zu Beginn der Warteschlange optimiert wird. Allerdings wei\u00df das OS nicht, wie lange ein bestimmter Prozess laufen wird, was<br \/>\ndas erforderliche Wissen f\u00fcr die Funktionsweise der SJF- und STCF-Algorithmen ist.<br \/>\nZweitens <b>, versucht der MLFQ<\/b>das System f\u00fcr die Benutzer (zum Beispiel f\u00fcr diejenigen, die vor dem Bildschirm sitzen und<br \/>\nauf den Abschluss einer Aufgabe warten) reaktionsschnell zu gestalten und somit die<br \/>\nAntwortzeit zu minimieren. Leider reduzieren Algorithmen wie RR die Antwortzeit, haben aber extrem<br \/>\nnegative Auswirkungen auf die Durchlaufzeit-Metrik. Daraus ergibt sich unser Problem: Wie entwerfen<br \/>\nwir einen Scheduler, der unseren Anforderungen entspricht und dabei nichts \u00fcber<br \/>\nein Scheduler, der unseren Anforderungen gerecht wird und gleichzeitig nichts \u00fcber<br \/>\nWas ist der allgemeine Charakter des Prozesses? Wie kann ein Planer die Eigenschaften der Aufgaben,<br \/>\ndie er ausf\u00fchrt, untersuchen und dadurch bessere Entscheidungen f\u00fcr die Planung treffen?<\/p>\n<p><u>Das Problem im Kern: Wie plant man die Aufgabenzuweisung ohne perfekte Kenntnisse?<br \/>\nWie entwickelt man einen Planer, der gleichzeitig die Reaktionszeit<br \/>\nf\u00fcr interaktive Aufgaben minimiert und zugleich die Bearbeitungszeit ohne vorhergehende<br \/>\nKenntnis der Ausf\u00fchrungszeit der Aufgabe reduziert?<\/u><\/p>\n<p>Hinweis: Lernen aus fr\u00fcheren Ereignissen<\/p>\n<p>Die MLFQ-Warteschlange ist ein ausgezeichnetes Beispiel f\u00fcr ein System, das auf<br \/>\nvergangenen Ereignissen lernt, um die Zukunft zu prognostizieren. Solche Ans\u00e4tze sind h\u00e4ufig<br \/>\nin Betriebssystemen (und vielen anderen Bereichen der Informatik anzutreffen, einschlie\u00dflich der Vorhersagezweige<br \/>\nin Hardware und Caching-Algorithmen). Solche Vorgehensweisen<br \/>\nfunktionieren, wenn Aufgaben Verhaltensphasen haben und daher vorhersehbar sind.<br \/>\nAllerdings sollte man mit dieser Technik vorsichtig sein, da Vorhersagen sehr schnell<br \/>\nfalsch sein k\u00f6nnen und das System zu schlechteren Entscheidungen f\u00fchren als<br \/>\nes ohne jegliches Wissen der Fall w\u00e4re.<\/p>\n<h3>MLFQ: Grundregeln<\/h3>\n<p>Betrachten wir die grundlegenden Regeln des MLFQ-Algorithmus. Obwohl es mehrere Implementierungen dieses Algorithmus gibt, sind die grundlegenden Ans\u00e4tze \u00e4hnlich.<br \/>\nIn der Implementierung, die wir betrachten werden, gibt es im MLFQ mehrere<br \/>\ngetrennte Warteschlangen, von denen jede eine andere Priorit\u00e4t hat. Zu jedem Zeitpunkt<br \/>\nbefindet sich eine aufrufbereite Aufgabe in einer Warteschlange. MLFQ verwendet Priorit\u00e4ten,<br \/>\num zu bestimmen, welche Aufgabe zur Ausf\u00fchrung kommt, d.h. die Aufgabe mit h\u00f6herer<br \/>\nPriorit\u00e4t (die Aufgabe aus der Warteschlange mit der h\u00f6chsten Priorit\u00e4t) wird als erste<br \/>\nausgef\u00fchrt.<br \/>\nEs ist unbestreitbar, dass in einer bestimmten Warteschlange mehr als eine Aufgabe sein kann, sodass<br \/>\ndiese den gleichen Priorit\u00e4tsgrad haben. In diesem Fall wird ein RR-Mechanismus verwendet,<br \/>\num die Ausf\u00fchrung unter diesen Aufgaben zu planen.<br \/>\nSomit gelangen wir zu zwei grundlegenden Regeln f\u00fcr MLFQ:<br \/>\nRegel 1: Wenn Priorit\u00e4t(A) &gt; Priorit\u00e4t(B), wird Aufgabe A gestartet (B nicht)<\/p>\n<ul>\n<li> Regel 2: Wenn Priorit\u00e4t(A) = Priorit\u00e4t(B), werden A und B mit RR gestartet.<\/li>\n<li> Aus dem oben Genannten ergibt sich, dass die Schl\u00fcsselfaktoren f\u00fcr die Planung von MLFQ<\/li>\n<\/ul>\n<p>die Priorit\u00e4ten sind. Anstatt jeder Aufgabe eine feste Priorit\u00e4t zuzuweisen,<br \/>\nPriorit\u00e4ten ist. Anstatt jedem eine feste Priorit\u00e4t zuzuweisen,<br \/>\nIm Rahmen der Aufgabe passt MLFQ die Priorit\u00e4t je nach beobachtetem Verhalten an.<br \/>\nWenn zum Beispiel eine Aufgabe st\u00e4ndig CPU-Ressourcen zur Eingabe von der Tastatur anfordert,<br \/>\nwird MLFQ die Priorit\u00e4t des Prozesses hoch halten, da dies dem entspricht, wie<br \/>\nein interaktiver Prozess funktionieren sollte. Im Gegensatz dazu, wenn eine Aufgabe konstant und<br \/>\nintensiv CPU f\u00fcr l\u00e4ngere Zeit nutzt, wird MLFQ dessen Priorit\u00e4t verringern.<br \/>\nAuf diese Weise wird MLFQ das Verhalten der Prozesse w\u00e4hrend ihrer Ausf\u00fchrung<br \/>\nstudieren und diese Beobachtungen nutzen.<br \/>\nLassen Sie uns ein Beispiel skizzieren, wie die Warteschlangen zu einem bestimmten Zeitpunkt<br \/>\naussehen k\u00f6nnten, und dann w\u00fcrde es etwa so aussehen:<br \/>\n<img decoding=\"async\" alt=\"Betriebssysteme: Drei einfache Teile. Teil 5: Planung: Multi-Level-Feedback-Warteschlange (\u00dcbersetzung)\" src=\"\/wp-content\/uploads\/2019\/04\/3598e9ca43a56049625bdcf3074de472.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>In diesem Diagramm befinden sich die Prozesse A und B in der Warteschlange mit der h\u00f6chsten Priorit\u00e4t. Der Prozess<br \/>\nC befindet sich irgendwo in der Mitte, w\u00e4hrend der Prozess D ganz hinten in der Warteschlange steht. Gem\u00e4\u00df der oben<br \/>\ngeschilderten Beschreibung des MLFQ-Algorithmus wird der Scheduler nur die Aufgaben mit der h\u00f6chsten<br \/>\nPriorit\u00e4t gem\u00e4\u00df RR ausf\u00fchren, w\u00e4hrend die Aufgaben C und D inaktiv bleiben.<br \/>\nEin statisches Snapshot gibt nat\u00fcrlich nicht das volle Bild dar\u00fcber, wie MLFQ funktioniert.<br \/>\nEs ist wichtig zu verstehen, wie sich das Bild im Laufe der Zeit ver\u00e4ndert.<\/p>\n<h4>Versuch 1: Wie man die Priorit\u00e4t \u00e4ndert<\/h4>\n<p>An diesem Punkt muss entschieden werden, wie MLFQ die Priorit\u00e4t der Aufgaben<br \/>\n\u00e4ndert (und damit die Position der Aufgabe in der Warteschlange) im Verlauf ihres Lebenszyklus. Um<br \/>\ndies zu erreichen, muss der Arbeitsablauf im Kopf behalten werden: eine bestimmte Anzahl<br \/>\ninteraktiver Aufgaben mit kurzer Laufzeit (und damit h\u00e4ufige Freigabe der<br \/>\nCPU) und mehrere langanhaltende Aufgaben, die die CPU w\u00e4hrend ihrer gesamten Arbeitszeit nutzen, wobei<br \/>\ndie Reaktionszeit f\u00fcr solche Aufgaben unwichtig ist. So kann ein erster Versuch gemacht werden,<br \/>\nden MLFQ-Algorithmus mit den folgenden Regeln zu implementieren:<\/p>\n<ul>\n<li> Regel 3: Wenn eine Aufgabe ins System kommt, wird sie in die Warteschlange mit der h\u00f6chsten<\/li>\n<li>Priorit\u00e4t eingestellt.<\/li>\n<li>Regel 4a: Wenn eine Aufgabe das ihr zugewiesene Zeitfenster vollst\u00e4ndig ausnutzt, wird ihre<\/li>\n<li>Priorit\u00e4t gesenkt.<\/li>\n<li>Regel 4b: Wenn eine Aufgabe die CPU vor Ablauf ihres Zeitfensters freigibt, bleibt sie<\/li>\n<li>mit der gleichen Priorit\u00e4t.<\/li>\n<\/ul>\n<p><b>Beispiel 1: Einzelne langlaufende Aufgabe<\/b><\/p>\n<p>Wie in diesem Beispiel zu sehen ist, wird die Aufgabe bei ihrem Eintreffen mit der h\u00f6chsten<br \/>\nPriorit\u00e4t gesetzt. Nach dem Zeitfenster von 10 ms wird die Priorit\u00e4t der Aufgabe durch<br \/>\nden Scheduler gesenkt. Nach dem n\u00e4chsten Zeitfenster wird die Aufgabe schlie\u00dflich herabgestuft bis<br \/>\nniedriger Priorit\u00e4t im System, wo sie bleibt.<br \/>\n<img decoding=\"async\" alt=\"Betriebssysteme: Drei einfache Teile. Teil 5: Planung: Multi-Level-Feedback-Warteschlange (\u00dcbersetzung)\" src=\"\/wp-content\/uploads\/2019\/04\/9b4ee6de03aa92d7957d50b4ffa73949.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p><b>Beispiel 2: Eine kurze Aufgabe wurde angezeigt.<\/b><\/p>\n<p>Lassen Sie uns nun ein Beispiel ansehen, wie MLFQ versucht, SJF zu approximieren. In diesem<br \/>\nBeispiel gibt es zwei Aufgaben: A, die eine langlaufende Aufgabe ist und st\u00e4ndig<br \/>\nCPU verwendet, und B, die eine kurze interaktive Aufgabe darstellt. Nehmen wir an,<br \/>\ndass A bereits einige Zeit gearbeitet hat, als Aufgabe B eintrifft.<br \/>\n<img decoding=\"async\" alt=\"Betriebssysteme: Drei einfache Teile. Teil 5: Planung: Multi-Level-Feedback-Warteschlange (\u00dcbersetzung)\" src=\"\/wp-content\/uploads\/2019\/04\/19c299b0519585fd1076a341a71f048b.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>In diesem Diagramm sind die Ergebnisse des Szenarios sichtbar. Aufgabe A, wie jede andere<br \/>\nAufgabe, die CPU verwendet, befindet sich ganz unten. Aufgabe B wird zu einem Zeitpunkt T=100<br \/>\neingereicht und erh\u00e4lt den h\u00f6chsten Priorit\u00e4tsplatz in der Warteschlange. Da ihre Ausf\u00fchrungszeit kurz<br \/>\nist, wird sie abgeschlossen, bevor sie die letzte Warteschlange erreicht.<\/p>\n<p>Aus diesem Beispiel sollte die Hauptzielsetzung des Algorithmus deutlich werden: Da der Algorithmus nicht<br \/>\nweiss, ob eine Aufgabe lang oder kurz ist, geht er zun\u00e4chst davon aus, dass die Aufgabe<br \/>\nkurz ist und gibt ihr die h\u00f6chste Priorit\u00e4t. Wenn es sich tats\u00e4chlich um eine kurze Aufgabe handelt,<br \/>\nwird sie schnell ausgef\u00fchrt, andernfalls, wenn es sich um eine lange Aufgabe handelt, wird sie langsam<br \/>\nin der Priorit\u00e4t nach unten wandern und bald beweisen, dass es sich um eine tats\u00e4chlich lange Aufgabe handelt, die nicht<br \/>\nerfordert eine Antwort.<\/p>\n<p><b>Beispiel 3: Was ist mit der Ein- und Ausgabe?<\/b><\/p>\n<p>Schauen wir uns nun ein Beispiel zur Ein- und Ausgabe an. Wie in Regel 4b erw\u00e4hnt,<br \/>\nwenn ein Prozess die CPU freigibt, ohne ihre gesamte Zeit zu nutzen,<br \/>\nbleibt er auf der gleichen Priorit\u00e4tsstufe. Die Absicht dieser Regel ist ziemlich einfach,<br \/>\nwenn eine interaktive Aufgabe viele Ein- und Ausgabeoperationen ausf\u00fchrt, indem sie beispielsweise<br \/>\nauf Tasteneingaben oder Mausklicks des Benutzers wartet, gibt diese Aufgabe die CPU<br \/>\nfr\u00fcher als zugewiesen frei. Wir m\u00f6chten solch eine Aufgabe nicht herabstufen,<br \/>\nund daher bleibt sie auf der gleichen Stufe.<br \/>\n<img decoding=\"async\" alt=\"Betriebssysteme: Drei einfache Teile. Teil 5: Planung: Multi-Level-Feedback-Warteschlange (\u00dcbersetzung)\" src=\"\/wp-content\/uploads\/2019\/04\/480d33a670fb62a639e5938dd59e30a1.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Dieses Beispiel zeigt, wie der Algorithmus mit solchen Prozessen arbeitet \u2013 interaktive Aufgabe B, die nur 1 ms CPU ben\u00f6tigt, bevor sie<br \/>\neinen Ein- und Ausgabeprozess ausf\u00fchrt, und die lang laufende Aufgabe A, die die gesamte CPU-Zeit nutzt.<br \/>\nMLFQ h\u00e4lt Prozess B auf der h\u00f6chsten Priorit\u00e4tsstufe, da er die CPU st\u00e4ndig freigibt.<br \/>\nWenn B eine interaktive Aufgabe ist, hat der Algorithmus in diesem Fall sein Ziel erreicht,<br \/>\ninteraktive Aufgaben schnell zu starten.<\/p>\n<p><b>Probleme mit dem aktuellen MLFQ-Algorithmus<\/b><\/p>\n<p>In den vorherigen Beispielen haben wir eine grundlegende Version von MLFQ erstellt. Es scheint, dass sie<br \/>\ngut funktioniert und die Prozessorzeit fair zwischen<br \/>\nlangwierigen Aufgaben verteilt, w\u00e4hrend sie k\u00fcrzeren Aufgaben oder solchen, die intensiv<br \/>\nauf Eingaben-Ausgaben zugreifen, schnell die M\u00f6glichkeit gibt, verarbeitet zu werden. Leider hat dieser Ansatz einige<br \/>\nernsthafte Probleme.<br \/>\n<b>Erstens<\/b>, das Hungerproblem: Wenn es im System viele interaktive<br \/>\nAufgaben gibt, verbrauchen diese die gesamte Prozessorzeit, sodass keine langwierige<br \/>\nAufgabe die M\u00f6glichkeit erh\u00e4lt, ausgef\u00fchrt zu werden (sie verhungern).<\/p>\n<p><b>, versucht der MLFQ<\/b>, versierte Benutzer k\u00f6nnten ihre Programme so schreiben, dass sie<br \/>\nden Scheduler \u00fcberlisten. Der Trick besteht darin, etwas zu tun, das den<br \/>\nScheduler dazu bringt, der Aufgabe mehr Prozessorzeit zuzuweisen. Der oben beschriebene<br \/>\nAlgorithmus ist durchaus anf\u00e4llig f\u00fcr solche Angriffe: Bevor das Zeitfenster praktisch<br \/>\nabgelaufen ist, muss eine Eingabe-Ausgabe-Operation (bei einer beliebigen, egal welcher Datei) durchgef\u00fchrt werden,<br \/>\num somit die CPU freizugeben. Ein solches Verhalten erlaubt es, im gleichen<br \/>\num die CPU-Zeit in der Warteschlange zu maximieren. Wenn dies richtig durchgef\u00fchrt wird,<br \/>\nzum Beispiel, indem sie 99% der Zeit im Vordergrund l\u00e4uft, bevor die CPU freigegeben wird,<br \/>\nkann eine solche Aufgabe einfach die gesamte Prozessorzeit monopolisiert.<\/p>\n<p>Schlie\u00dflich kann ein Programm im Laufe der Zeit sein Verhalten \u00e4ndern. Aufgaben,<br \/>\ndie zuerst CPU-intensive waren, k\u00f6nnten interaktiv werden. In unserem Beispiel<br \/>\nw\u00fcrden solche Aufgaben nicht die dringend ben\u00f6tigte Aufmerksamkeit vom Scheduler erhalten,<br \/>\nweil sie anderen (urspr\u00fcnglichen) interaktiven Aufgaben vorgezogen werden w\u00fcrden.<\/p>\n<p><u>Frage an die Runde: Welche Angriffe auf den Scheduler k\u00f6nnten in der heutigen Welt ausgef\u00fchrt werden?<br \/>\n<\/u><\/p>\n<h4>Versuch 2: Priorit\u00e4tserh\u00f6hung<\/h4>\n<p>Versuchen wir, die Regeln zu \u00e4ndern und zu sehen, ob wir das Problem der<br \/>\nHungersnot umgehen k\u00f6nnen. Was k\u00f6nnten wir tun, um sicherzustellen, dass CPU-gebundene<br \/>\nAufgaben ihre Zeit erhalten (auch wenn nicht lange)?<br \/>\nAls einfache L\u00f6sung f\u00fcr dieses Problem k\u00f6nnte man vorschlagen,<br \/>\nregelm\u00e4\u00dfig die Priorit\u00e4t aller solchen Aufgaben im System zu erh\u00f6hen. Es gibt viele M\u00f6glichkeiten,<br \/>\ndies zu erreichen, lassen Sie uns ein einfaches Beispiel umsetzen: eine \u00dcbersetzung.<br \/>\nAlle Aufgaben sofort in h\u00f6chste Priorit\u00e4t setzen, daher die neue Regel:<\/p>\n<ul>\n<li><b>Regel5<\/b>: Nach einer gewissen Zeit S alle Aufgaben im System in die h\u00f6chste Warteschlange versetzen.<\/li>\n<\/ul>\n<p>Unsere neue Regel l\u00f6st sofort zwei Probleme. Erstens, die Prozesse<br \/>\nsind garantiert nicht unterversorgt: Aufgaben in der h\u00f6chsten Warteschlange erhalten<br \/>\ndie Prozesszeit gem\u00e4\u00df dem RR-Algorithmus und dadurch erh\u00e4lt jeder Prozess<br \/>\nProzesszeit. Zweitens, wenn ein Prozess, der zuvor nur CPU-Ressourcen genutzt hat, interaktiv wird,<br \/>\nbleibt er in der Warteschlange mit der h\u00f6chsten Priorit\u00e4t, nachdem er einmal die Priorit\u00e4t auf die h\u00f6chste<br \/>\nerhoben hat.<br \/>\nBetrachten wir ein Beispiel. In diesem Szenario betrachten wir einen Prozess, der verwendet<br \/>\n<img decoding=\"async\" alt=\"Betriebssysteme: Drei einfache Teile. Teil 5: Planung: Multi-Level-Feedback-Warteschlange (\u00dcbersetzung)\" src=\"\/wp-content\/uploads\/2019\/04\/3b8d879ab4479622684b126ec5af6af3.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>CPU und zwei interaktive, kurze Prozesse. Auf der linken Seite zeigt die Abbildung das Verhalten ohne Priorisierungserh\u00f6hung, wodurch eine langwierige Aufgabe hungert, nachdem zwei interaktive Aufgaben ins System eintreten. Auf der rechten Seite wird alle 50 ms eine Priorit\u00e4tserh\u00f6hung durchgef\u00fchrt, sodass alle Prozesse garantiert CPU-Zeit erhalten und regelm\u00e4\u00dfig ausgef\u00fchrt werden. 50 ms dienen hier als Beispiel; in der Realit\u00e4t ist diese Zahl etwas h\u00f6her.<br \/>\nEs ist offensichtlich, dass die Hinzuf\u00fcgung von periodischer Erh\u00f6hungszeit S zu<br \/>\nder zwangsl\u00e4ufigen Frage f\u00fchrt: Welcher Wert sollte festgelegt werden? Einer der angesehenen<br \/>\nSystemingenieure, John Ousterhout, nannte derartige Gr\u00f6\u00dfen in Systemen voo-doo<br \/>\nKonstanten, da sie irgendwie schwarze Magie zur korrekten<br \/>\nEinstellung erforderten. Und leider hat S einen \u00e4hnlichen Geschmack. Wenn der Wert zu hoch eingestellt wird,<br \/>\nbeginnen langwierige Aufgaben zu hungern. Wenn der Wert jedoch zu niedrig eingestellt wird,<br \/>\nerhalten die interaktiven Aufgaben nicht die erforderliche CPU-Zeit.<\/p>\n<h4>Versuch 3: Bessere Ber\u00fccksichtigung<\/h4>\n<p>Jetzt haben wir ein weiteres Problem, das gel\u00f6st werden muss: Wie verhindern wir,<br \/>\ndass unser Scheduler ausgetrickst wird? Verantwortlich f\u00fcr diese M\u00f6glichkeit sind<br \/>\ndie Regeln 4a und 4b, die es einer Aufgabe erlauben, ihre Priorit\u00e4t zu behalten und den Prozessor<br \/>\nbis zum Ende der zugewiesenen Zeit zu entlasten. Wie gehen wir damit um?<br \/>\nEine L\u00f6sung in diesem Fall k\u00f6nnte die bessere Zeiterfassung der CPU auf jedem<br \/>\nMLFQ-Level sein. Anstatt die Zeit zu ignorieren, die ein Programm w\u00e4hrend eines<br \/>\nbestimmten Zeitraums f\u00fcr die CPU verwendet hat, sollte diese berechnet und aufgezeichnet werden. Sobald<br \/>\nder Prozess seine zugewiesene Zeit aufgebraucht hat, sollte er auf die n\u00e4chste<br \/>\nPriorit\u00e4tsstufe herabgestuft werden. Es spielt jetzt keine Rolle, wie der Prozess seine Zeit nutzt \u2013 ob<br \/>\ner st\u00e4ndig auf der CPU rechnet oder eine Vielzahl von Aufrufen macht. Daher sollte<br \/>\nRegel 4 wie folgt umgeschrieben werden:<\/p>\n<ul>\n<li><b>Rule4<\/b>: Sobald eine Aufgabe ihre ihr zugewiesene Zeit in der aktuellen Warteschlange aufgebraucht hat (unabh\u00e4ngig davon, wie oft sie die CPU freigegeben hat), wird die Priorit\u00e4t dieser Aufgabe herabgestuft (sie bewegt sich nach unten in der Warteschlange).<\/li>\n<\/ul>\n<p>Schauen wir uns ein Beispiel an:<br \/>\n<img decoding=\"async\" alt=\"Betriebssysteme: Drei einfache Teile. Teil 5: Planung: Multi-Level-Feedback-Warteschlange (\u00dcbersetzung)\" src=\"\/wp-content\/uploads\/2019\/04\/18c53e62b9b342d14a23995bd422ef5e.png\" style=\"display:block;margin: 0 auto;\">\u00bb<\/p>\n<p>Die Abbildung zeigt, was passiert, wenn man versucht, den Scheduler auszutricksen, als<br \/>\nw\u00e4re es mit den vorherigen Regeln 4a, 4b auf der linken Seite. Mit der neuen<br \/>\nRegel \u2013 das Ergebnis auf der rechten Seite. Vor der Aktivierung des Schutzes konnte jeder Prozess I\/O bis zum Abschluss anfordern und<br \/>\nsomit die CPU dominieren. Nach der Aktivierung des Schutzes, unabh\u00e4ngig vom Verhalten<br \/>\nvon I\/O, wird er dennoch in den Warteschlangen nach unten rutschen und somit nicht unrechtm\u00e4\u00dfig<br \/>\nauf die CPU-Ressourcen zugreifen k\u00f6nnen.<\/p>\n<h4>Verbesserung von MLFQ und anderen Problemen<\/h4>\n<p>Mit den oben genannten Verbesserungen tauchen neue Probleme auf: Eine der Hauptfragen ist, wie man einen solchen Scheduler parametrieren sollte. Das hei\u00dft, wie viele<br \/>\nWarteschlangen sollten vorhanden sein? Wie gro\u00df sollte das Zeitfenster f\u00fcr die Programmausf\u00fchrung innerhalb der Warteschlange sein? Wie<br \/>\noft sollte die Priorit\u00e4t eines Programms erh\u00f6ht werden, um Hunger zu vermeiden und<br \/>\nVerhaltens\u00e4nderungen des Programms zu ber\u00fccksichtigen? Auf diese Fragen gibt es keine einfache<br \/>\nAntwort und nur Experimente mit Lasten sowie anschlie\u00dfende Konfigurationen<br \/>\ndes Schedulers k\u00f6nnen zu einem gewissen befriedigenden Gleichgewicht f\u00fchren.<br \/>\nZum Beispiel erlauben die meisten Implementierungen von MLFQ, verschiedene<\/p>\n<p>beispielsweise erlauben die meisten MLFQ-Implementierungen die Zuordnung unterschiedlicher<br \/>\nZeitintervalle f\u00fcr verschiedene Warteschlangen. Hochpriorisierte Warteschlangen erhalten in der Regel<br \/>\nkurze Intervalle. Diese Warteschlangen bestehen aus interaktiven Aufgaben,<br \/>\nzwischen denen das Umschalten recht sensibel ist und weniger als 10<br \/>\nms in Anspruch nehmen sollte. Im Gegensatz dazu bestehen niedrigpriorisierte Warteschlangen aus langen Aufgaben, die CPU<br \/>\nnutzen. Daher sind l\u00e4ngere Zeitintervalle hier sehr geeignet (100 ms).<br \/>\n<img decoding=\"async\" alt=\"Betriebssysteme: Drei einfache Teile. Teil 5: Planung: Multi-Level-Feedback-Warteschlange (\u00dcbersetzung)\" src=\"\/wp-content\/uploads\/2019\/04\/4eb6c6669034adeb1615c29454fbb1dc.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>In diesem Beispiel gibt es 2 Aufgaben, die in der Hochpriorit\u00e4tswarteschlange 20<br \/>\nms gearbeitet haben, aufgeteilt in Fenster von 10 ms. 40 ms in der mittleren Warteschlange (Fenster von 20 ms) und in der niedrigpriorisierten<br \/>\nWarteschlange wurde das Zeitfenster auf 40 ms gesetzt, wo die Aufgaben ihre Arbeit abgeschlossen haben.<\/p>\n<p>Die Implementierung von MLFQ im Solaris-Betriebssystem ist eine Art von Planer, der zeitlich aufteilt.<br \/>\nDer Planer stellt eine Reihe von Tabellen bereit, die genau definieren, wie sich<br \/>\ndie Priorit\u00e4t eines Prozesses im Laufe seiner Lebensdauer \u00e4ndern sollte, wie gro\u00df das<br \/>\nzugewiesene Fenster sein sollte und wie oft die Priorit\u00e4ten der Aufgabe erh\u00f6ht werden m\u00fcssen. Der Administrator<br \/>\ndes Systems kann mit dieser Tabelle interagieren und den Planer anweisen, sich entsprechend zu verhalten.<br \/>\nanders. Standardm\u00e4\u00dfig enth\u00e4lt diese Tabelle 60 Warteschlangen mit allm\u00e4hlicher Erh\u00f6hung<br \/>\nder Fenstergr\u00f6\u00dfe von 20 ms (hohe Priorit\u00e4t) bis zu mehreren hundert ms (geringe Priorit\u00e4t) und<br \/>\neinem Boost aller Aufgaben einmal pro Sekunde.<\/p>\n<p>Andere MLFQ-Planer verwenden keine Tabelle oder spezifischen<br \/>\nRegeln, die in dieser Vorlesung beschrieben sind; stattdessen berechnen sie Priorit\u00e4ten mit<br \/>\nmathematischen Formeln. So verwendet beispielsweise der Planer in FreeBSD eine Formel zur<br \/>\nBerechnung der aktuellen Priorit\u00e4t einer Aufgabe, basierend darauf, wie viel Prozess<br \/>\nCPU-Ressourcen verbraucht hat. Dar\u00fcber hinaus verschlechtert sich die CPU-Auslastung<br \/>\nim Laufe der Zeit, sodass die Erh\u00f6hung der Priorit\u00e4t etwas anders erfolgt als oben beschrieben. Dies sind die<br \/>\nsogenannten Decay-Algorithmen. Seit Version 7.1 verwendet FreeBSD den ULE-Planer.<\/p>\n<p>Schlie\u00dflich haben viele Planer andere Eigenschaften. Zum Beispiel reservieren einige<br \/>\nPlaner h\u00f6here Priorit\u00e4ten f\u00fcr das Betriebssystem, sodass kein Benutzerprozess die h\u00f6chste<br \/>\nPriorit\u00e4t im System erreichen kann. Einige Systeme erlauben es, Hinweise zu geben, um zu helfen<br \/>\nSysteme. Einige Systeme bieten Ratschl\u00e4ge, um zu helfen<br \/>\nEs ist wichtig, dass der Scheduler die Priorit\u00e4ten korrekt festlegt. Zum Beispiel kann mit dem Befehl <b>nice<\/b><br \/>\ndie Priorit\u00e4t einer Aufgabe erh\u00f6ht oder verringert werden, um so die Chancen des Programms auf CPU-Zeit zu verbessern oder zu verschlechtern.<br \/>\ndie Chancen eines Programms auf CPU-Zeit zu verringern.<\/p>\n<h3>MLFQ: Zusammenfassung<\/h3>\n<p>Wir haben einen Planungsansatz beschrieben, der MLFQ genannt wird. Der Name basiert auf dem Funktionsprinzip \u2014 er verwendet mehrere Warteschlangen und nutzt R\u00fcckmeldungen<br \/>\num die Priorit\u00e4t einer Aufgabe festzulegen.<br \/>\nDie finale Regel sieht wie folgt aus:<br \/>\nRegel 1<\/p>\n<ul>\n<li><b>: Wenn Priorit\u00e4t(A) &gt; Priorit\u00e4t(B), wird Aufgabe A gestartet (B nicht).<\/b>Regel 2<\/li>\n<li><b>: Wenn Priorit\u00e4t(A) = Priorit\u00e4t(B), werden A und B mit RR gestartet.<\/b>Regel 3<\/li>\n<li><b>: Wenn eine Aufgabe in das System kommt, wird sie in die Warteschlange mit der h\u00f6chsten Priorit\u00e4t eingeordnet.<\/b>MLFQ ist aus folgendem Grund interessant \u2014 anstatt dass er im Voraus Kenntnisse \u00fcber die Natur der Aufgabe erfordert, lernt der Algorithmus aus dem vergangenen Verhalten der Aufgabe und passt die<\/li>\n<li><b>Rule4<\/b>: Sobald eine Aufgabe ihre ihr zugewiesene Zeit in der aktuellen Warteschlange aufgebraucht hat (unabh\u00e4ngig davon, wie oft sie die CPU freigegeben hat), wird die Priorit\u00e4t dieser Aufgabe herabgestuft (sie bewegt sich nach unten in der Warteschlange).<\/li>\n<li><b>Regel5<\/b>: Nach einer gewissen Zeit S alle Aufgaben im System in die h\u00f6chste Warteschlange versetzen.<\/li>\n<\/ul>\n<p>Priorit\u00e4ten entsprechend an. So versucht er, gleichzeitig zwei Ziele zu erreichen \u2014 Leistung f\u00fcr kleine Aufgaben (SJF, STCF) und die faire Ausf\u00fchrung l\u00e4ngerer,<br \/>\nCPU-intensiver Auftr\u00e4ge. Deshalb setzen viele Systeme, einschlie\u00dflich BSD und deren Abk\u00f6mmlinge, darauf.<br \/>\nPriorit\u00e4ten entsprechend. So versucht er, auf zwei Hochzeiten gleichzeitig zu tanzen \u2013 die Leistung f\u00fcr kleinere Aufgaben (SJF, STCF) zu maximieren und gleichzeitig l\u00e4ngere,<br \/>\nCPU-intensiven Aufgaben gerecht zu werden. Daher nutzen viele Systeme, einschlie\u00dflich BSD und deren Ableger,<br \/>\nSolaris, Windows und Mac verwenden eine Form von Algorithmus als Scheduler.<br \/>\nMLFQ als grundlegendes Konzept.<\/p>\n<h4>Zus\u00e4tzliche Materialien:<\/h4>\n<ol>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/manpages.debian.org\/stretch\/manpages\/sched.7.en.html\">manpages.debian.org\/stretch\/manpages\/sched.7.de.html<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Scheduling_\">de.wikipedia.org\/wiki\/Planung_<\/a><\/noindex>(Informatik)<\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/pages.lip6.fr\/Julia.Lawall\/atc18-bouron.pdf\">pages.lip6.fr\/Julia.Lawall\/atc18-bouron.pdf<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.usenix.org\/legacy\/event\/bsdcon03\/tech\/full_papers\/roberson\/roberson.pdf\">www.usenix.org\/legacy\/event\/bsdcon03\/tech\/full_papers\/roberson\/roberson.pdf<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/chebykin.org\/freebsd-process-scheduling\">chebykin.org\/freebsd-prozessplanung<\/a><\/noindex><\/li>\n<\/ol>\n<p>Quelle: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/post\/450116\/\">habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0425\u043e\u0447\u0443 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0432\u0430\u0448\u0435\u043c\u0443 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044e \u0441\u0435\u0440\u0438\u044e \u0441\u0442\u0430\u0442\u0435\u0439-\u043f\u0435\u0440\u0435\u0432\u043e\u0434\u043e\u0432 \u043e\u0434\u043d\u043e\u0439 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e\u0439 \u043d\u0430 \u043c\u043e\u0439 \u0432\u0437\u0433\u043b\u044f\u0434 \u043b\u0438\u0442\u0435\u0440\u0430\u0442\u0443\u0440\u044b \u2014 OSTEP. \u0412 \u044d\u0442\u043e\u043c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0435 \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0433\u043b\u0443\u0431\u043e\u043a\u043e \u0440\u0430\u0431\u043e\u0442\u0430 unix-\u043f\u043e\u0434\u043e\u0431\u043d\u044b\u0445 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c, \u0430 \u0438\u043c\u0435\u043d\u043d\u043e \u2014 \u0440\u0430\u0431\u043e\u0442\u0430 \u0441 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430\u043c\u0438, \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u043c\u0438 \u043f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0449\u0438\u043a\u0430\u043c\u0438, \u043f\u0430\u043c\u044f\u0442\u044c\u044e \u0438 \u043f\u0440\u043e\u0447\u0438\u0438\u043c\u0438 \u043f\u043e\u0434\u043e\u0431\u043d\u044b\u043c\u0438 \u043a\u043e\u043c\u043f\u043e\u043d\u0435\u043d\u0442\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u044e\u0442 \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u0443\u044e \u041e\u0421. \u041e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0432\u0441\u0435\u0445 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u0432 \u0432\u044b \u043c\u043e\u0436\u0435\u0442\u0435 \u043f\u043e\u0441\u043c\u043e\u0442\u0440\u0435\u0442\u044c \u0432\u043e\u0442 \u0442\u0443\u0442. [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":24514,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-32730","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 4.9.10 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0425\u043e\u0447\u0443 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0432\u0430\u0448\u0435\u043c\u0443 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044e \u0441\u0435\u0440\u0438\u044e \u0441\u0442\u0430\u0442\u0435\u0439-\u043f\u0435\u0440\u0435\u0432\u043e\u0434\u043e\u0432 \u043e\u0434\u043d\u043e\u0439 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e\u0439 \u043d\u0430 \u043c\u043e\u0439 \u0432\u0437\u0433\u043b\u044f\u0434 \u043b\u0438\u0442\u0435\u0440\u0430\u0442\u0443\u0440\u044b \u2014 OSTEP. \u0412 \u044d\u0442\u043e\u043c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0435 \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0433\u043b\u0443\u0431\u043e\u043a\u043e \u0440\u0430\u0431\u043e\u0442\u0430 unix-\u043f\u043e\u0434\u043e\u0431\u043d\u044b\u0445 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c, \u0430 \u0438\u043c\u0435\u043d\u043d\u043e \u2014 \u0440\u0430\u0431\u043e\u0442\u0430 \u0441 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430\u043c\u0438, \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u043c\u0438 \u043f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0449\u0438\u043a\u0430\u043c\u0438, \u043f\u0430\u043c\u044f\u0442\u044c\u044e \u0438 \u043f\u0440\u043e\u0447\u0438\u0438\u043c\u0438 \u043f\u043e\u0434\u043e\u0431\u043d\u044b\u043c\u0438 \u043a\u043e\u043c\u043f\u043e\u043d\u0435\u043d\u0442\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u044e\u0442 \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u0443\u044e \u041e\u0421. \u041e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0432\u0441\u0435\u0445 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u0432 \u0432\u044b \u043c\u043e\u0436\u0435\u0442\u0435 \u043f\u043e\u0441\u043c\u043e\u0442\u0440\u0435\u0442\u044c \u0432\u043e\u0442 \u0442\u0443\u0442.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/operating-systems-three-easy-pieces-part-5-planirovanie-multi-level-feedback-queue-perevod\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 4.9.10\" \/>\n\t\t<meta property=\"og:locale\" content=\"de_DE\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Operating Systems: Three Easy Pieces. Part 5: \u041f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435: Multi-Level Feedback Queue (\u043f\u0435\u0440\u0435\u0432\u043e\u0434) | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0425\u043e\u0447\u0443 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0432\u0430\u0448\u0435\u043c\u0443 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044e \u0441\u0435\u0440\u0438\u044e \u0441\u0442\u0430\u0442\u0435\u0439-\u043f\u0435\u0440\u0435\u0432\u043e\u0434\u043e\u0432 \u043e\u0434\u043d\u043e\u0439 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e\u0439 \u043d\u0430 \u043c\u043e\u0439 \u0432\u0437\u0433\u043b\u044f\u0434 \u043b\u0438\u0442\u0435\u0440\u0430\u0442\u0443\u0440\u044b \u2014 OSTEP. \u0412 \u044d\u0442\u043e\u043c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0435 \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0433\u043b\u0443\u0431\u043e\u043a\u043e \u0440\u0430\u0431\u043e\u0442\u0430 unix-\u043f\u043e\u0434\u043e\u0431\u043d\u044b\u0445 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c, \u0430 \u0438\u043c\u0435\u043d\u043d\u043e \u2014 \u0440\u0430\u0431\u043e\u0442\u0430 \u0441 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430\u043c\u0438, \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u043c\u0438 \u043f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0449\u0438\u043a\u0430\u043c\u0438, \u043f\u0430\u043c\u044f\u0442\u044c\u044e \u0438 \u043f\u0440\u043e\u0447\u0438\u0438\u043c\u0438 \u043f\u043e\u0434\u043e\u0431\u043d\u044b\u043c\u0438 \u043a\u043e\u043c\u043f\u043e\u043d\u0435\u043d\u0442\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u044e\u0442 \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u0443\u044e \u041e\u0421. \u041e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0432\u0441\u0435\u0445 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u0432 \u0432\u044b \u043c\u043e\u0436\u0435\u0442\u0435 \u043f\u043e\u0441\u043c\u043e\u0442\u0440\u0435\u0442\u044c \u0432\u043e\u0442 \u0442\u0443\u0442.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/operating-systems-three-easy-pieces-part-5-planirovanie-multi-level-feedback-queue-perevod\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2019-10-31T18:48:36+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2021-02-08T09:40:35+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Betriebssysteme: Drei einfache Teile. Teil 5: Planung: Mehrstufige Feedback-Warteschlange (\u00dcbersetzung) | ProHoster","description":"Einf\u00fchrung in Betriebssysteme\nHallo, Habr! Ich m\u00f6chte Ihnen eine Serie von \u00dcbersetzungen einer interessanten Literatur vorstellen \u2013 OSTEP. In diesem Material wird die Funktionsweise von unix-\u00e4hnlichen Betriebssystemen ausf\u00fchrlich behandelt, insbesondere die Arbeit mit Prozessen, verschiedenen Scheduler, Speicher und anderen \u00e4hnlichen Komponenten, die ein modernes Betriebssystem ausmachen. Das Original aller Materialien k\u00f6nnen Sie hier ansehen.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/operating-systems-three-easy-pieces-part-5-planirovanie-multi-level-feedback-queue-perevod","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Operating Systems: Three Easy Pieces. Part 5: \u041f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435: Multi-Level Feedback Queue (\u043f\u0435\u0440\u0435\u0432\u043e\u0434) | ProHoster","og:description":"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0425\u043e\u0447\u0443 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0432\u0430\u0448\u0435\u043c\u0443 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044e \u0441\u0435\u0440\u0438\u044e \u0441\u0442\u0430\u0442\u0435\u0439-\u043f\u0435\u0440\u0435\u0432\u043e\u0434\u043e\u0432 \u043e\u0434\u043d\u043e\u0439 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e\u0439 \u043d\u0430 \u043c\u043e\u0439 \u0432\u0437\u0433\u043b\u044f\u0434 \u043b\u0438\u0442\u0435\u0440\u0430\u0442\u0443\u0440\u044b \u2014 OSTEP. \u0412 \u044d\u0442\u043e\u043c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0435 \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0433\u043b\u0443\u0431\u043e\u043a\u043e \u0440\u0430\u0431\u043e\u0442\u0430 unix-\u043f\u043e\u0434\u043e\u0431\u043d\u044b\u0445 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c, \u0430 \u0438\u043c\u0435\u043d\u043d\u043e \u2014 \u0440\u0430\u0431\u043e\u0442\u0430 \u0441 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430\u043c\u0438, \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u043c\u0438 \u043f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0449\u0438\u043a\u0430\u043c\u0438, \u043f\u0430\u043c\u044f\u0442\u044c\u044e \u0438 \u043f\u0440\u043e\u0447\u0438\u0438\u043c\u0438 \u043f\u043e\u0434\u043e\u0431\u043d\u044b\u043c\u0438 \u043a\u043e\u043c\u043f\u043e\u043d\u0435\u043d\u0442\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u044e\u0442 \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u0443\u044e \u041e\u0421. \u041e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0432\u0441\u0435\u0445 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u0432 \u0432\u044b \u043c\u043e\u0436\u0435\u0442\u0435 \u043f\u043e\u0441\u043c\u043e\u0442\u0440\u0435\u0442\u044c \u0432\u043e\u0442 \u0442\u0443\u0442.","og:url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/operating-systems-three-easy-pieces-part-5-planirovanie-multi-level-feedback-queue-perevod","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T18:48:36+00:00","article:modified_time":"2021-02-08T09:40:35+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"32730","title":null,"description":"","keywords":"","keyphrases":null,"primary_term":null,"canonical_url":"","og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-21 12:18:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 02:53:25","updated":"2026-01-21 12:18:19"},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/32730","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=32730"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/32730\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/24514"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=32730"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=32730"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=32730"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}