{"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 St\u00fccke. 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 Ihnen eine Serie von \u00dcbersetzungen einer interessanten Literatur \u2014 OSTEP \u2014 vorstellen. In diesem Material wird die Funktionsweise von Unix-\u00e4hnlichen Betriebssystemen ziemlich gr\u00fcndlich behandelt, insbesondere die Arbeit mit Prozessen, verschiedenen Planern, Speicher und anderen \u00e4hnlichen Komponenten, die ein modernes Betriebssystem ausmachen. Das Original aller Materialien k\u00f6nnen Sie hier ansehen <noindex><a rel=\"nofollow\" href=\"http:\/\/pages.cs.wisc.edu\/~remzi\/OSTEP\/\">hier<\/a><\/noindex>. Bitte beachten Sie, dass die \u00dcbersetzung unprofessionell (relativ frei) durchgef\u00fchrt wurde, aber ich hoffe, dass ich den allgemeinen Sinn bewahrt habe.<\/p>\n<p>Die Laborarbeiten zu diesem Thema finden Sie 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>Andere 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 Scheduler<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/450116\/\">Teil 5: MLFQ Scheduler<\/a><\/noindex><\/li>\n<\/ul>\n<p>Und Sie k\u00f6nnen auch meinen Kanal auf <noindex><a rel=\"nofollow\" href=\"https:\/\/t.me\/bykvaadm\">Telegramm<\/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 \u00fcber die Herausforderungen bei der Entwicklung eines der bekanntesten Ans\u00e4tze zur<br \/>\nPlanung sprechen, der als <b>Multi-Level Feedback Queue<\/b> (MLFQ) bezeichnet wird. Der MLFQ Scheduler wurde erstmals 1962 von Fernando J. Corbat\u00f3 im System beschrieben, das<br \/>\nCompatible Time-Sharing System (CTSS) genannt wird. Diese Arbeiten (einschlie\u00dflich sp\u00e4terer Arbeiten an<br \/>\nMultics) wurden sp\u00e4ter f\u00fcr den Turing Award nominiert. Der Scheduler wurde<br \/>\nsp\u00e4ter weiter verbessert und nahm eine Form an, die man bereits in<br \/>\neinigen modernen Systemen antreffen kann.<\/p>\n<p>Der MLFQ-Algorithmus versucht, zwei grundlegende, sich \u00fcberschneidende Probleme zu l\u00f6sen.<br \/>\n<b>Zun\u00e4chst einmal<\/b>, er versucht, die Durchlaufzeit zu optimieren, die, wie wir in der vorherigen Vorlesung betrachtet haben, durch das Starten der k\u00fcrzesten<br \/>\nAufgaben zu Beginn der Warteschlange optimiert wird. Allerdings wei\u00df das OS nicht, wie lange ein bestimmter Prozess arbeiten wird, was<br \/>\ndas notwendige Wissen f\u00fcr die Algorithmen SJF, STCF ist. <b>Zweitens<\/b>, MLFQ versucht,<br \/>\ndas System reaktionsschnell f\u00fcr die Benutzer zu machen (zum Beispiel f\u00fcr diejenigen, die warten und<br \/>\nauf ihren Bildschirm starren, in der Erwartung, dass die Aufgabe abgeschlossen wird) und damit die Zeit<br \/>\nder Reaktion zu minimieren. Leider verringern Algorithmen wie RR die Reaktionszeit, haben aber \u00e4u\u00dferst<br \/>\nnegative Auswirkungen auf die Durchlaufzeit-Metrik. Daher unser Problem: Wie entwirft man einen<br \/>\nScheduler, der unseren Anforderungen entspricht und dabei nichts \u00fcber die<br \/>\nCharakteristik des Prozesses im Allgemeinen wei\u00df? Wie kann der Scheduler die Eigenschaften der Aufgaben lernen,<br \/>\ndie er ausf\u00fchrt, und dadurch bessere Entscheidungen bez\u00fcglich der Planung treffen?<\/p>\n<p><u>Die Kernproblematik: Wie plant man Aufgaben ohne perfektes Wissen?<br \/>\nWie gestaltet man einen Scheduler, der gleichzeitig die Reaktionszeit minimiert<br \/>\nf\u00fcr interaktive Aufgaben und dabei die Durchlaufzeit minimiert, ohne im Voraus.<br \/>\ndas Zeitverhalten der Aufgabe zu kennen?<\/u><\/p>\n<p>Hinweis: Lernend aus vergangenen Ereignissen<\/p>\n<p>Die MLFQ-Warteschlange ist ein hervorragendes Beispiel f\u00fcr ein System, das aus<br \/>\nvergangenen Ereignissen lernt, um die Zukunft vorherzusagen. Solche Ans\u00e4tze sind h\u00e4ufig<br \/>\nin Betriebssystemen zu finden (und in vielen anderen Bereichen der Informatik, einschlie\u00dflich der Bereiche<br \/>\nVorhersagen in Hardware und Algorithmen zur Caching). \u00c4hnliche Ans\u00e4tze<br \/>\nwirken, wenn Aufgaben Verhaltensphasen haben und somit vorhersagbar sind.<br \/>\nAllerdings sollte man mit dieser Technik vorsichtig sein, da Vorhersagen sehr leicht<br \/>\nfalsch sein k\u00f6nnen und das System zu schlechteren Entscheidungen f\u00fchren k\u00f6nnen als<br \/>\nohne jegliches Wissen.<\/p>\n<h3>MLFQ: Grundregeln<\/h3>\n<p>Betrachten wir die Grundregeln des MLFQ-Algorithmus. Und obwohl es verschiedene<br \/>\nImplementierungen dieses Algorithmus gibt, sind die grundlegenden Ans\u00e4tze \u00e4hnlich.<br \/>\nIn der Implementierung, die wir betrachten werden, wird MLFQ mehrere<br \/>\neinzelne Warteschlangen haben, von denen jede eine unterschiedliche Priorit\u00e4t hat. Zu jeder Zeit<br \/>\nbefindet sich eine aufbereitete Aufgabe in einer Warteschlange. MLFQ verwendet Priorit\u00e4ten,<br \/>\num zu entscheiden, welche Aufgabe zur Ausf\u00fchrung gebracht werden soll, d.h. die Aufgabe mit<br \/>\nh\u00f6herer Priorit\u00e4t (Aufgabe aus der Warteschlange mit h\u00f6chster Priorit\u00e4t) wird zuerst<br \/>\nausgef\u00fchrt.<br \/>\nZweifellos kann in einer bestimmten Warteschlange mehr als eine Aufgabe sein, damit<br \/>\nhaben sie die gleiche Priorit\u00e4t. In diesem Fall wird der RR-Mechanismus<br \/>\nzur Planung der Ausf\u00fchrung unter diesen Aufgaben verwendet.<br \/>\nSo kommen wir zu zwei grundlegenden Regeln f\u00fcr MLFQ:<\/p>\n<ul>\n<li> Regel 1: Wenn Priorit\u00e4t(A) &gt; Priorit\u00e4t(B), wird Aufgabe A ausgef\u00fchrt (B nicht)<\/li>\n<li> Regel 2: Wenn Priorit\u00e4t(A) = Priorit\u00e4t(B), werden A und B unter Verwendung von RR ausgef\u00fchrt<\/li>\n<\/ul>\n<p>Aus den obigen Punkten ergeben sich die Schl\u00fcsselfaktoren f\u00fcr die MLFQ-Planung<br \/>\nsind die Priorit\u00e4ten. Anstatt jeder<br \/>\nAufgabe eine feste Priorit\u00e4t zuzuweisen, \u00e4ndert MLFQ ihre Priorit\u00e4t basierend auf dem beobachteten Verhalten.<br \/>\nWenn eine Aufgabe beispielsweise st\u00e4ndig Arbeiten auf der CPU ausf\u00fchrt, w\u00e4hrend sie auf Eingaben von der Tastatur wartet,<br \/>\nwird MLFQ die Priorit\u00e4t des Prozesses hoch halten, da genau das so<br \/>\nein interaktiver Prozess funktionieren sollte. Wenn hingegen die Aufgabe st\u00e4ndig und<br \/>\nintensiv die CPU \u00fcber einen l\u00e4ngeren Zeitraum nutzt, wird MLFQ ihre<br \/>\nPriorit\u00e4t senken. Auf diese Weise wird MLFQ das Verhalten der Prozesse w\u00e4hrend ihrer Ausf\u00fchrung studieren<br \/>\nund verwenden.<br \/>\nLassen Sie uns ein Beispiel zeichnen, wie die Warteschlangen zu einem bestimmten Zeitpunkt<br \/>\naussehen k\u00f6nnten, und dann w\u00fcrde dies etwa so aussehen:<br \/>\n<img decoding=\"async\" alt=\"Betriebssysteme: Drei einfache St\u00fccke. 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 Szenario befinden sich 2 Prozesse A und B in der Warteschlange mit der h\u00f6chsten Priorit\u00e4t. Prozess<br \/>\nC befindet sich irgendwo in der Mitte, und Prozess D am Ende der Warteschlange. Gem\u00e4\u00df den obigen<br \/>\nBeschreibungen des MLFQ-Algorithmus wird der Scheduler nur Aufgaben mit der h\u00f6chsten Priorit\u00e4t ausf\u00fchren.<br \/>\nPriorit\u00e4t gem\u00e4\u00df RR, w\u00e4hrend die Aufgaben C und D nicht ber\u00fccksichtigt werden.<br \/>\nNat\u00fcrlich wird ein statischer Snapshot nicht das volle Bild davon geben, 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>In diesem Moment muss entschieden werden, wie MLFQ das Priorit\u00e4tsniveau<br \/>\nder Aufgaben (und damit deren Position in der Warteschlange) im Verlauf ihres Lebenszyklus \u00e4ndert. Dazu<br \/>\nmuss man den Arbeitsablauf im Kopf behalten: Eine bestimmte Anzahl<br \/>\ninteraktiver Aufgaben mit kurzer Laufzeit (und somit h\u00e4ufige Freigabe<br \/>\nder CPU) und mehrere langwierige Aufgaben, die die CPU die gesamte Arbeitszeit nutzen, wobei<br \/>\ndie Reaktionszeit f\u00fcr solche Aufgaben nicht wichtig ist. Somit kann der erste Versuch<br \/>\nunternehmen werden, den MLFQ-Algorithmus mit folgenden Regeln zu implementieren:<\/p>\n<ul>\n<li> Regel 3: Wenn eine Aufgabe in das System eintritt, wird sie in die Warteschlange mit der h\u00f6chsten<\/li>\n<li>Priorit\u00e4t festgelegt wurde.<\/li>\n<li>Regel 4a: Wenn eine Aufgabe ihr zugewiesenes Zeitfenster vollst\u00e4ndig nutzt, wird ihre<\/li>\n<li>Priorit\u00e4t gesenkt.<\/li>\n<li>Regel 4b: Wenn die Aufgabe die CPU vor Ablauf ihres Zeitfensters freigibt,<\/li>\n<li>beh\u00e4lt sie ihre vorherige Priorit\u00e4t.<\/li>\n<\/ul>\n<p><b>Beispiel 1: Eine einzelne langlaufende Aufgabe<\/b><\/p>\n<p>Wie in diesem Beispiel zu sehen ist, wird die Aufgabe beim Eingang mit der h\u00f6chsten<br \/>\nPriorit\u00e4t eingestuft. Nach einem Zeitfenster von 10 ms wird die Priorit\u00e4t durch den<br \/>\nScheduler gesenkt. Nach dem n\u00e4chsten Zeitfenster wird die Aufgabe schlie\u00dflich auf<br \/>\ndie niedrigste Priorit\u00e4t im System herabgestuft, wo sie verbleibt.<br \/>\n<img decoding=\"async\" alt=\"Betriebssysteme: Drei einfache St\u00fccke. 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 hinzugef\u00fcgt<\/b><\/p>\n<p>Jetzt schauen wir uns ein Beispiel an, wie MLFQ versucht, sich SJF anzun\u00e4hern. In diesem<br \/>\nBeispiel gibt es zwei Aufgaben: A, die eine langlaufende Aufgabe ist, die st\u00e4ndig<br \/>\nCPU beansprucht, und B, die eine kurze interaktive Aufgabe ist. Angenommen,<br \/>\nA hat bereits eine gewisse Zeit gearbeitet, als die Aufgabe B eintrifft.<br \/>\n<img decoding=\"async\" alt=\"Betriebssysteme: Drei einfache St\u00fccke. 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 Aufgabe,<br \/>\ndie die CPU nutzt, befindet sich ganz unten. Aufgabe B wird zu Zeitpunkt T=100 eintreffen und wird<br \/>\nin die Warteschlange mit der h\u00f6chsten Priorit\u00e4t platziert. Da ihre Laufzeit kurz ist, wird<br \/>\nsie abgeschlossen, bevor sie die letzte Warteschlange erreicht.<\/p>\n<p>Aus diesem Beispiel l\u00e4sst sich das Hauptziel des Algorithmus ableiten: Da der Algorithmus nicht<br \/>\nwei\u00df, ob es sich um eine lange oder kurze Aufgabe handelt, geht er zun\u00e4chst davon aus, dass es sich um eine Aufgabe handelt.<br \/>\nkurz und gibt ihr die h\u00f6chste Priorit\u00e4t. Wenn es sich tats\u00e4chlich um eine kurze Aufgabe handelt, dann<br \/>\nwird sie schnell ausgef\u00fchrt, andernfalls, wenn es sich um eine lange Aufgabe handelt, wird sie sich langsam bewegen<br \/>\nnach unten in der Priorit\u00e4t und bald beweisen, dass es sich tats\u00e4chlich um eine lange Aufgabe handelt, die nicht<br \/>\neine R\u00fcckmeldung erfordert.<\/p>\n<p><b>Beispiel 3: Was ist mit der Ein- und Ausgabe?<\/b><\/p>\n<p>Lassen Sie uns nun das Beispiel mit Ein- und Ausgabe betrachten. Wie in Regel 4b gesagt,<br \/>\nwenn ein Prozess den Prozessor freigibt, ohne seine gesamte Prozessorzeit vollst\u00e4ndig genutzt zu haben,<br \/>\ndann bleibt er auf dem bisherigen Priorit\u00e4tsniveau. Die Absichten dieser Regel sind recht einfach<br \/>\n\u2014 wenn eine interaktive Aufgabe viele Ein- und Ausgabeoperationen ausf\u00fchrt, zum Beispiel, wenn sie auf<br \/>\nBenutzereingaben wie Tastatureingaben oder Mausklicks wartet, wird eine solche Aufgabe den Prozessor<br \/>\nfr\u00fcher von dem zugewiesenen Zeitfenster befreien. Wir m\u00f6chten eine solche Aufgabe nicht herabstufen,<br \/>\ndeshalb bleibt sie auf dem gleichen Niveau.<br \/>\n<img decoding=\"async\" alt=\"Betriebssysteme: Drei einfache St\u00fccke. 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 - die interaktive Aufgabe B, die nur 1 ms CPU ben\u00f6tigt, bevor sie die<br \/>\nEin- und Ausgabeprozesse ausf\u00fchrt, und die lange Aufgabe A, die die gesamte CPU-Zeit nutzt.<br \/>\nMLFQ h\u00e4lt den Prozess B mit der h\u00f6chsten Priorit\u00e4t, da er st\u00e4ndig<br \/>\nden CPU freigibt. Wenn B eine interaktive Aufgabe ist, dann hat der Algorithmus in diesem Fall sein Ziel erreicht,<br \/>\ninteraktive Aufgaben schnell auszuf\u00fchren.<\/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 entwickelt. Und es scheint, dass er<br \/>\nseine Arbeit gut macht und fair, indem er die Prozessorzeit gerecht zwischen<br \/>\nlangen Aufgaben verteilt und kurzen Aufgaben oder solchen, die intensiv Eingaben verarbeiten, die M\u00f6glichkeit gibt, schnell zu arbeiten. Leider enth\u00e4lt dieser Ansatz mehrere<br \/>\nernsthafte Probleme.<br \/>\n, das Hungersnot-Problem: Wenn es im System viele interaktive<br \/>\n<b>Zun\u00e4chst einmal<\/b>Aufgaben gibt, werden sie die gesamte Prozessorzeit beanspruchen und somit wird keine lange<br \/>\nAufgabe die M\u00f6glichkeit erhalten, ausgef\u00fchrt zu werden (sie verhungern).<br \/>\n, clevere Benutzer k\u00f6nnten ihre Programme so schreiben, dass sie<\/p>\n<p><b>Zweitens<\/b>den Scheduler \u00fcberlisten. Der Trick besteht darin, etwas zu tun, das dazu f\u00fchrt, dass der<br \/>\nScheduler dem Prozess mehr Prozessorzeit zuweist. Der Algorithmus, der<br \/>\nDer Planer wird dem Prozess mehr Prozessorzeit zuweisen. Der Algorithmus, der<br \/>\nWie oben beschrieben, ist es durchaus anf\u00e4llig f\u00fcr derartige Angriffe: Bevor das Zeitfenster praktisch<br \/>\nabgelaufen ist, muss eine Ein- oder Ausgabeoperation (f\u00fcr eine bestimmte, gleichg\u00fcltig welche Datei) durchgef\u00fchrt werden<br \/>\nund damit die CPU freigegeben werden. Ein solches Verhalten erm\u00f6glicht es, in der gleichen<br \/>\nWarteschlange zu bleiben und erneut einen h\u00f6heren Prozentsatz an CPU-Zeit zu erhalten. Wenn das richtig gemacht wird (zum Beispiel 99% der Zeit im Fenster vor der Freigabe der CPU auszuf\u00fchren),<br \/>\nkann eine solche Aufgabe einfach monopolistisch die CPU nutzen.<br \/>\nSchlie\u00dflich kann das Programm sein Verhalten im Laufe der Zeit \u00e4ndern. Die Aufgaben,<\/p>\n<p>die die CPU verwendet haben, k\u00f6nnen interaktiv werden. In unserem Beispiel erhalten solche<br \/>\nAufgaben nicht die angemessene Behandlung vom Scheduler, da sie andere<br \/>\n(urspr\u00fcngliche) interaktive Aufgaben erhalten h\u00e4tten.<br \/>\nFrage an das Publikum: Welche Angriffe auf den Scheduler k\u00f6nnten in der modernen Welt durchgef\u00fchrt werden?<\/p>\n<p><u>Versuch 2: Priorit\u00e4tserh\u00f6hung<br \/>\n<\/u><\/p>\n<h4>Lassen Sie uns versuchen, die Regeln zu \u00e4ndern und zu sehen, ob wir es schaffen, Probleme mit<\/h4>\n<p>Hunger zu vermeiden. Was k\u00f6nnten wir tun, um zu gew\u00e4hrleisten, dass die mit<br \/>\nCPU verbundenen Aufgaben ihre Zeit erhalten (auch wenn nicht viel).<br \/>\nAls einfache L\u00f6sung des Problems kann man vorschlagen, alle solchen Aufgaben im System periodisch<br \/>\nin der Priorit\u00e4t zu erh\u00f6hen. Es gibt viele M\u00f6glichkeiten, dies zu erreichen; lassen Sie uns als Beispiel etwas Einfaches umsetzen: Alle<br \/>\nAufgaben sofort in die h\u00f6chste Priorit\u00e4t zu versetzen, von dort ein neues Regelwerk:<br \/>\nRegel5<br \/>\n: Nach einer bestimmten Zeitspanne S alle Aufgaben im System in die h\u00f6chste Warteschlange versetzen.<\/p>\n<ul>\n<li><b>Unser neues Regelwerk l\u00f6st sofort zwei Probleme. Erstens, Prozesse<\/b>verhungern garantiert nicht: Aufgaben, die sich in der h\u00f6heren Warteschlange befinden, werden die<\/li>\n<\/ul>\n<p>CPU-Zeit gem\u00e4\u00df dem RR-Algorithmus teilen, sodass alle Prozesse<br \/>\nCPU-Zeit erhalten. Zweitens, wenn ein Prozess, der zuvor nur die CPU verwendet hat, interaktiv wird, bleibt er in der Warteschlange mit der h\u00f6heren<br \/>\nPriorit\u00e4t, nachdem er einmal in die h\u00f6chste Priorit\u00e4t erh\u00f6ht wurde.<br \/>\nBetrachten wir ein Beispiel. In diesem Szenario betrachten wir einen Prozess, der die<br \/>\nnur die CPU betrifft, wird interaktiv und bleibt in der Warteschlange mit h\u00f6herer<br \/>\nPriorit\u00e4t, nachdem er einmal in die h\u00f6chste Priorit\u00e4t bef\u00f6rdert wurde.<br \/>\nBetrachten wir ein Beispiel. In diesem Szenario betrachten wir einen Prozess, der<br \/>\n<img decoding=\"async\" alt=\"Betriebssysteme: Drei einfache St\u00fccke. 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. Links zeigt die Abbildung das Verhalten ohne Priorit\u00e4tserh\u00f6hung, wodurch eine langwierige Aufgabe nach dem Eintreffen von zwei interaktiven Aufgaben im System verhungern beginnt. Auf der rechten Seite wird alle 50 ms eine Priorit\u00e4tserh\u00f6hung durchgef\u00fchrt, sodass alle Prozesse garantiert CPU-Zeit erhalten und periodisch ausgef\u00fchrt werden. 50 ms wurde in diesem Fall als Beispiel gew\u00e4hlt, tats\u00e4chlich ist diese Zahl etwas h\u00f6her.<br \/>\nOffensichtlich f\u00fchrt die Hinzuf\u00fcgung der Zeit f\u00fcr die periodische Erh\u00f6hung S zu<br \/>\nder berechtigten Frage: Welcher Wert sollte festgelegt werden? Einer der angesehenen<br \/>\nSystemingenieure, John Ousterhout, nannte solche Gr\u00f6\u00dfen in Systemen voo-doo<br \/>\nKonstanten, da sie in gewissem Sinne schwarze Magie f\u00fcr die korrekte<br \/>\nFestlegung erforderten. Und leider hat S diesen Charakter. Wenn der Wert zu hoch<br \/>\ngesetzt wird, beginnen lange Aufgaben zu verhungern. Ist der Wert zu niedrig,<br \/>\nerhalten interaktive Aufgaben nicht die n\u00f6tige CPU-Zeit.<\/p>\n<h4>Versuch 3: Beste Zeiterfassung<\/h4>\n<p>Nun haben wir ein weiteres Problem, das gel\u00f6st werden muss: Wie k\u00f6nnen wir<br \/>\nverhindern, dass unser Scheduler ausgetrickst wird? Die Schuld tragen<br \/>\ndie Regeln 4a, 4b, die es einer Aufgabe erm\u00f6glichen, ihre Priorit\u00e4t beizubehalten, indem sie die CPU<br \/>\nvor Ablauf der zugewiesenen Zeit freigibt. Wie gehen wir damit um?<br \/>\nIn diesem Fall kann eine bessere Zeiterfassung der CPU auf jedem<br \/>\nLevel von MLFQ als L\u00f6sung angesehen werden. Anstatt die Zeit, die das Programm verwendet hat,<br \/>\num CPU \u00fcber den festgelegten Zeitraum zu nutzen, sollte diese erfasst und gespeichert werden. Nachdem<br \/>\nein Prozess die ihm zugewiesene Zeit aufgebraucht hat, sollte sein Priorit\u00e4tslevel auf das n\u00e4chste<br \/>\nniedrigere Niveau gesenkt werden. Jetzt spielt es keine Rolle, wie der Prozess seine Zeit verwendet \u2013 ob<br \/>\ner st\u00e4ndig rechnend auf der CPU oder durch zahlreiche Aufrufe agiert. Somit<br \/>\nsollte Regel 4 wie folgt umgeschrieben werden:<\/p>\n<ul>\n<li><b>Regel4<\/b>: Nachdem eine Aufgabe die 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 gesenkt (sie bewegt sich weiter unten in der Warteschlange).<\/li>\n<\/ul>\n<p>Sehen wir uns ein Beispiel an:<br \/>\n<img decoding=\"async\" alt=\"Betriebssysteme: Drei einfache St\u00fccke. 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, wie<br \/>\nWenn man die vorherigen Regeln 4a, 4b anwendet, ergibt sich das Ergebnis links. Mit der neuen<br \/>\nRegel \u2013 das Ergebnis rechts. Vor der Aktivierung der Schutzmechanismen konnte jeder Prozess I\/O bis zur<br \/>\nFertigstellung aufrufen und so die CPU dominieren. Nach Aktivierung des Schutzes wird er jedoch, unabh\u00e4ngig vom Verhalten<br \/>\nder I\/O, immer weiter unten in die Warteschlangen eingestuft und kann somit nicht unrechtm\u00e4\u00dfig<br \/>\nauf die CPU-Ressourcen zugreifen.<\/p>\n<h4>Verbesserungen von MLFQ und anderen Problemen<\/h4>\n<p>Mit den oben genannten Verbesserungen entstehen neue Probleme: Eine der Hauptfragen ist, wie ein<br \/>\nsolcher Scheduler parametrisiert werden sollte? Das hei\u00dft, wie viele Warteschlangen sollten vorhanden sein?<br \/>\nWie gro\u00df sollte das Arbeitsfenster des Programms innerhalb der Warteschlange sein? Wie<br \/>\nh\u00e4ufig 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 und anschlie\u00dfende Anpassungen<br \/>\ndes Schedulers k\u00f6nnen zu einem einigerma\u00dfen zufriedenstellenden Gleichgewicht f\u00fchren.<\/p>\n<p>Beispielsweise erlauben die meisten Implementierungen von MLFQ die Zuweisung unterschiedlicher<br \/>\nZeitintervalle zu verschiedenen Warteschlangen. Hochpriorisierte Warteschlangen erhalten in der Regel<br \/>\nkurze Intervalle. Diese Warteschlangen bestehen aus interaktiven Aufgaben,<br \/>\nzwischen denen der Wechsel recht empfindlich ist und etwa 10 Millisekunden oder weniger<br \/>\ndauern sollte. Im Gegensatz dazu bestehen niedrigpriorisierte Warteschlangen aus langen Aufgaben, die<br \/>\ndie CPU verwenden. In diesem Fall sind lange Zeitintervalle sehr passend (100 ms).<br \/>\n<img decoding=\"async\" alt=\"Betriebssysteme: Drei einfache St\u00fccke. 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 20 Millisekunden in der hochpriorisierten Warteschlange gearbeitet haben,<br \/>\naufgeteilt in Fenster von 10 Millisekunden. 40 Millisekunden in der mittleren Warteschlange (Fenster von 20 Millisekunden) und in der niedrigpriorisierten<br \/>\nWarteschlange betrug das tempor\u00e4re Fenster 40 Millisekunden, in dem die Aufgaben ihre Arbeit abgeschlossen haben.<\/p>\n<p>Die Umsetzung von MLFQ im Betriebssystem Solaris ist eine Klasse von zeitscheibenden Scheduler.<br \/>\nDer Scheduler bietet eine Reihe von Tabellen an, die genau definieren, wie sich die Priorit\u00e4t eines Prozesses im Laufe<br \/>\nseines Lebens \u00e4ndern sollte, wie gro\u00df das zugeteilte Fenster sein sollte und wie oft die Priorit\u00e4ten<br \/>\neiner Aufgabe erh\u00f6ht werden m\u00fcssen. Der Systemadministrator<br \/>\nkann mit dieser Tabelle interagieren und den Scheduler dazu bringen, sich<br \/>\nanders zu verhalten. Standardm\u00e4\u00dfig enth\u00e4lt diese Tabelle 60 Warteschlangen mit schrittweise zunehmender<br \/>\nFenstergr\u00f6\u00dfe von 20 ms (hohe Priorit\u00e4t) bis mehrere Hundert ms (niedrige Priorit\u00e4t), und<br \/>\nauch mit Boost f\u00fcr alle Aufgaben einmal pro Sekunde.<\/p>\n<p>Andere MLFQ-Planer verwenden keine Tabelle oder spezifische<br \/>\nRegeln, die in dieser Vorlesung beschrieben sind, sondern berechnen Priorit\u00e4ten unter Verwendung<br \/>\nmathematischer Formeln. So verwendet beispielsweise der Planer in FreeBSD eine Formel zur<br \/>\nBerechnung der aktuellen Priorit\u00e4t einer Aufgabe, basierend darauf, wie viel der Prozess<br \/>\nCPU verwendet hat. Dar\u00fcber hinaus verrottet die CPU-Nutzung im Laufe der Zeit, und somit<br \/>\ngeschieht die Priorit\u00e4tensteigerung etwas anders, als oben beschrieben. Dies sind die<br \/>\nsogenannten Abklingalgorithmen. Seit Version 7.1 wird in FreeBSD der ULE-Planer verwendet.<\/p>\n<p>Schlie\u00dflich haben viele Planer andere Besonderheiten. Zum Beispiel reservieren einige<br \/>\nPlaner die h\u00f6chsten Ebenen f\u00fcr das Betriebssystem, sodass kein Benutzerprozess die h\u00f6chste<br \/>\nPriorit\u00e4t im System erhalten kann. Einige Systeme erm\u00f6glichen es, Hinweise zu geben, um<br \/>\ndem Planer zu helfen, Priorit\u00e4ten korrekt festzulegen. So kann man beispielsweise mit dem Befehl<br \/>\ndie Priorit\u00e4t einer Aufgabe erh\u00f6hen oder verringern und damit die Chancen des Programms auf Zeit <b>nice<\/b><br \/>\nauf der CPU erh\u00f6hen oder senken.<br \/>\nMLFQ: Ergebnisse<\/p>\n<h3>Wir haben einen Ansatz zur Planung beschrieben, der MLFQ genannt wird. Sein Name<\/h3>\n<p>entspricht dem Prinzip seiner Arbeitsweise \u2013 er hat mehrere Warteschlangen und nutzt Feedback<br \/>\nzur Bestimmung der Priorit\u00e4t einer Aufgabe.<br \/>\nDie endg\u00fcltige Form der Regeln wird wie folgt sein:<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 ins System kommt, wird sie in die Warteschlange mit der h\u00f6chsten Priorit\u00e4t gelegt.<\/b>MLFQ ist aus folgendem Grund interessant \u2013 anstatt im Voraus Wissen \u00fcber<\/li>\n<li><b>Regel4<\/b>: Nachdem eine Aufgabe die 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 gesenkt (sie bewegt sich weiter unten in der Warteschlange).<\/li>\n<li><b>Unser neues Regelwerk l\u00f6st sofort zwei Probleme. Erstens, Prozesse<\/b>verhungern garantiert nicht: Aufgaben, die sich in der h\u00f6heren Warteschlange befinden, werden die<\/li>\n<\/ul>\n<p>die Natur der Aufgabe zu verlangen, lernt der Algorithmus aus dem bisherigen Verhalten der Aufgabe und legt<br \/>\ndie Priorit\u00e4ten entsprechend fest. So versucht er, gleichzeitig zwei St\u00fchle zu besetzen \u2013 sowohl Leistung f\u00fcr kurze Aufgaben (SJF, STCF) zu erreichen als auch fair lange,<br \/>\nCPU-intensive Aufgaben zu starten. Deshalb verwenden viele Systeme, einschlie\u00dflich BSD und ihrer Derivate,<br \/>\nSolaris, Windows, Mac eine gewisse Form des MLFQ-Algorithmus als grundlegende Grundlage.<br \/>\nmanpages.debian.org\/stretch\/manpages\/sched.7.en.html<br \/>\nen.wikipedia.org\/wiki\/Scheduling_<\/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\">(computing)<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Scheduling_\">chebykin.org\/freebsd-process-scheduling<\/a><\/noindex>(computing)<\/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-process-scheduling<\/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 5.0.1.1 - 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.\" \/>\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) 5.0.1.1\" \/>\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.\" \/>\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 St\u00fccke. Teil 5: Planung: Multi-Level-Feedback-Warteschlange (\u00dcbersetzung) | ProHoster","description":"Einf\u00fchrung in Betriebssysteme Hallo, Habr! Ich m\u00f6chte Ihnen eine Reihe von Artikel\u00fcbersetzungen einer interessanten Literatur \u2014 OSTEP \u2014 vorstellen.","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.","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","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"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}]}}