{"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\/nl\/blog\/administrirovanie\/operating-systems-three-easy-pieces-part-5-planirovanie-multi-level-feedback-queue-perevod","title":{"rendered":"Operating Systems: Three Easy Pieces. Deel 5: Planning: Multi-Level Feedback Queue (vertaling).","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<h1>Inleiding tot besturingssystemen<\/h1>\n<p>Hallo, Habr! Ik wil jullie een serie vertaalde artikelen voorstellen van een literatuur die ik interessant vind - OSTEP. In dit materiaal wordt diep ingegaan op de werking van Unix-achtige besturingssystemen, met name - hoe processen werken, verschillende planners, geheugen en andere soortgelijke componenten die een modern besturingssysteem vormen. Het origineel van al het materiaal kunt u hier bekijken <noindex><a rel=\"nofollow\" href=\"http:\/\/pages.cs.wisc.edu\/~remzi\/OSTEP\/\">here<\/a><\/noindex>. Houd er rekening mee dat de vertaling niet professioneel is uitgevoerd (vrij vrij), maar ik hoop dat ik de algemene betekenis heb behouden.<\/p>\n<p>Laboratoriumopdrachten voor dit onderwerp kun je hier vinden:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"http:\/\/pages.cs.wisc.edu\/~remzi\/OSTEP\/Homework\/homework.html\">origineel<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/remzi-arpacidusseau\/ostep-code\">origineel<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/bykvaadm\/OS\/tree\/master\/ostep\">mijn persoonlijke adaptatie<\/a><\/noindex><\/li>\n<\/ul>\n<p>Andere delen:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/446340\/\">Deel 1: Intro<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/446866\/\">Deel 2: Abstractie: proces<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/447182\/\">Deel 3: Introductie tot proces-API's<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/449026\/\">Deel 4: Introductie tot de planner<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/450116\/\">Deel 5: MLFQ Planner<\/a><\/noindex><\/li>\n<\/ul>\n<p>En je kunt ook mijn kanaal bezoeken op <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>Planning: Multi-Level Feedback Queue<\/h2>\n<p>In deze lezing zullen we het hebben over de problemen bij het ontwikkelen van een van de bekendste benaderingen voor<br \/>\nplanning, die worden aangeduid als <b>Multi-Level Feedback Queue<\/b> (MLFQ). De MLFQ planner werd voor het eerst beschreven in 1962 door Fernando J. Corbat\u00f3 in een systeem dat werd genoemd<br \/>\nCompatible Time-Sharing System (CTSS). Dit werk (inclusief latere studies over<br \/>\nMultics) werd later genomineerd voor de Turing Award. De planner werd<br \/>\nlater verbeterd en kreeg de vorm die we al in<br \/>\nsommige moderne systemen tegenkomen.<\/p>\n<p>Het MLFQ-algoritme probeert twee fundamentele, elkaar overlappende problemen op te lossen.<br \/>\n<b>Firstly<\/b>, het probeert de doorlooptijd te optimaliseren, wat we in de vorige lezing bespraken, door de kortste taken eerst in de rij te plaatsen.<br \/>\nEchter, het besturingssysteem weet niet hoe lang een bepaald proces zal draaien, en dat is<br \/>\nnoodzakelijke kennis voor de werking van SJF- en STCF-algoritmen. <b>Secondly<\/b>, MLFQ probeert<br \/>\nhet systeem responsief te maken voor gebruikers (bijvoorbeeld voor diegenen die zitten en<br \/>\nnaar het scherm staren in afwachting van het voltooien van een taak) en zo de tijd<br \/>\nvan reactie te minimaliseren. Helaas verminderen algoritmes zoals RR de reactietijd, maar hebben extreme<br \/>\nnegatieve effecten op de doorlooptijdmetrieken. Dit leidt ons tot het probleem: Hoe ontwerpen we een<br \/>\nplanner die aan onze vereisten voldoet en tegelijkertijd niets weet over<br \/>\nde aard van het proces in het algemeen? Hoe kan de planner de eigenschappen van de taken die hij uitvoert leren,<br \/>\nen zo betere beslissingen nemen over de planning?<\/p>\n<p><u>De kern van het probleem: Hoe taken plannen zonder perfecte kennis?<br \/>\nHoe een planner ontwikkelen die de reactietijd minimaliseert.<br \/>\nvoor interactieve taken en minimaliseert tegelijkertijd de doorlooptijd zonder enige voorafgaande kennis<br \/>\nvan de uitvoeringstijd van de taak?<\/u><\/p>\n<p>Opmerking: we leren van eerdere gebeurtenissen<\/p>\n<p>De MLFQ-queue is een uitstekend voorbeeld van een systeem dat leert van<br \/>\nafgelopen gebeurtenissen om de toekomst te voorspellen. Dergelijke benaderingen worden vaak<br \/>\naangetroffen in besturingssystemen (en in veel andere gebieden binnen de informatica, inclusief takken<br \/>\nvan voorspellingen in hardware en algoritmes voor caching). Dergelijke benaderingen<br \/>\nfunctioneren goed wanneer taken gedragsfases hebben en dus voorspelbaar zijn.<br \/>\nEchter, met deze techniek moet voorzichtigheid worden betracht, omdat voorspellingen zeer gemakkelijk<br \/>\nonjuist kunnen zijn en het systeem kunnen leiden tot slechtere beslissingen dan<br \/>\nwanneer er helemaal geen kennis is.<\/p>\n<h3>MLFQ: Basisregels<\/h3>\n<p>Laten we de basisregels van het MLFQ-algoritme bekijken. En hoewel er verschillende implementaties van dit algoritme<br \/>\nbestaan, zijn de basisbenaderingen vergelijkbaar.<br \/>\nIn de implementatie die we zullen bespreken, heeft MLFQ meerdere<br \/>\nafzonderlijke queues, elk met een andere prioriteit. Op elk moment,<br \/>\nbevindt de taak die klaar is voor uitvoering zich in een van de queues. MLFQ gebruikt prioriteiten<br \/>\nom te bepalen welke taak moet worden uitgevoerd, dat wil zeggen dat de taak met een hogere<br \/>\nprioriteit (de taak uit de queue met de hoogste prioriteit) als eerste zal worden uitgevoerd.<br \/>\nZeker, in een specifieke queue kan er meer dan \u00e9\u00e9n taak zijn, zodat<br \/>\nze dezelfde prioriteit hebben. In dit geval wordt het RR-mechanisme gebruikt<br \/>\nvoor het plannen van de uitvoering tussen deze taken.<br \/>\nZo komen we aan twee basisregels voor MLFQ:<br \/>\nRegel 1: Als prioriteit(A) &gt; prioriteit(B), zal taak A worden uitgevoerd (B niet)<\/p>\n<ul>\n<li> Regel 2: Als prioriteit(A) = prioriteit(B), worden A en B uitgevoerd met behulp van RR<\/li>\n<li> Op basis van het bovenstaande zijn de belangrijkste elementen voor MLFQ-planning<\/li>\n<\/ul>\n<p>de prioriteiten. In plaats van elke taak een vaste prioriteit toe te kennen,<br \/>\npast MLFQ de prioriteit aan op basis van het waargenomen gedrag.<br \/>\nBijvoorbeeld, als een taak voortdurend CPU-werk opzij zet in afwachting van invoer van het toetsenbord,<br \/>\nzal MLFQ de prioriteit van het proces op een hoog niveau houden, omdat dit is wat<br \/>\neen interactief proces zou moeten doen. Aan de andere kant, als de taak voortdurend en<br \/>\ner moet een interactief proces zijn. Echter, als het tegenovergestelde het geval is, is de taak constant en<br \/>\nintensief het CPU gedurende een lange periode gebruikt, zal MLFQ het verlagen<br \/>\nprioriteit. Op deze manier zal MLFQ het gedrag van processen tijdens hun uitvoering bestuderen<br \/>\nen gebruik maken van de gedragingen.<br \/>\nLaten we een voorbeeld schetsen van hoe de wachtrijen op een bepaald moment eruit zouden kunnen zien.<br \/>\nHet resultaat zou er ongeveer als volgt uitzien:<br \/>\n<img decoding=\"async\" alt=\"Operating Systems: Three Easy Pieces. Deel 5: Planning: Multi-Level Feedback Queue (vertaling).\" src=\"\/wp-content\/uploads\/2019\/04\/3598e9ca43a56049625bdcf3074de472.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>In dit schema bevinden zich 2 processen A en B in de wachtrij met de hoogste prioriteit. Proces<br \/>\nC bevindt zich ergens in het midden, terwijl proces D aan het einde van de wachtrij staat. Volgens de bovenstaande<br \/>\nbeschrijvingen van het MLFQ-algoritme zal de planner alleen taken met de hoogste<br \/>\nprioriteit uitvoeren volgens RR, terwijl taken C en D geen aandacht zullen krijgen.<br \/>\nNatuurlijk geeft een statische snapshot niet het volledige beeld van hoe MLFQ werkt.<br \/>\nHet is belangrijk te begrijpen hoe het beeld in de loop van de tijd verandert.<\/p>\n<h4>Poging 1: Hoe prioriteit te veranderen<\/h4>\n<p>Op dit punt moet worden beslist hoe MLFQ het prioriteitsniveau van<br \/>\neen taak (en bijgevolg de positie van de taak in de wachtrij) tijdens de levenscyclus zal veranderen. Hiervoor<br \/>\nmoet je het werkproces in gedachten houden: een aantal<br \/>\ninteractieve taken met een korte uitvoeringstijd (en dus frequente vrijgeving van<br \/>\nCPU) en enkele lange taken die de CPU de hele tijd gebruiken, terwijl<br \/>\nde responstijd voor dergelijke taken niet belangrijk is. En zo kan de eerste poging worden gedaan<br \/>\nom het MLFQ-algoritme met de volgende regels te implementeren:<\/p>\n<ul>\n<li> Regel 3: Wanneer een taak het systeem binnenkomt, wordt deze in de wachtrij met de hoogste<\/li>\n<li>prioriteit geplaatst.<\/li>\n<li>Regel 4a: Als een taak het toegewezen tijdvenster volledig gebruikt, wordt haar<\/li>\n<li>prioriteit verlaagd.<\/li>\n<li>Regel 4b: Als een taak de CPU v\u00f3\u00f3r het verstrijken van zijn tijdvenster vrijgeeft, blijft zij<\/li>\n<li>met dezelfde prioriteit.<\/li>\n<\/ul>\n<p><b>Voorbeeld 1: Een enkele langdurige taak<\/b><\/p>\n<p>Zoals zichtbaar in dit voorbeeld, wordt de taak bij binnenkomst met de hoogste<br \/>\nprioriteit ingesteld. Na een tijdvenster van 10 ms wordt de prioriteit<br \/>\ndoor de planner verlaagd. Na het volgende tijdvenster wordt de taak eindelijk verlaagd naar<br \/>\nde laagste prioriteit in het systeem, waar deze blijft.<br \/>\n<img decoding=\"async\" alt=\"Operating Systems: Three Easy Pieces. Deel 5: Planning: Multi-Level Feedback Queue (vertaling).\" src=\"\/wp-content\/uploads\/2019\/04\/9b4ee6de03aa92d7957d50b4ffa73949.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p><b>Voorbeeld 2: Een korte taak afgeleverd<\/b><\/p>\n<p>Laten we nu een voorbeeld bekijken van hoe MLFQ zal proberen zich te benaderen tot SJF. In dit<br \/>\nvoorbeeld zijn er twee taken: A, die een langdurige taak is die constant<br \/>\nde CPU gebruikt, en B, die een korte interactieve taak is. Stel dat,<br \/>\nA werkte al enige tijd toen de taak B binnenkwam.<br \/>\n<img decoding=\"async\" alt=\"Operating Systems: Three Easy Pieces. Deel 5: Planning: Multi-Level Feedback Queue (vertaling).\" src=\"\/wp-content\/uploads\/2019\/04\/19c299b0519585fd1076a341a71f048b.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>De resultaten van het scenario zijn zichtbaar in deze grafiek. Taak A, net als elke taak,<br \/>\ndie CPU gebruikt, bevond zich onderaan. Taak B komt aan op tijd T=100 en zal<br \/>\nin de wachtrij met de hoogste prioriteit worden geplaatst. Aangezien de tijd die nodig is voor<br \/>\ndeze taak kort is, zal ze klaar zijn voordat ze de laatste wachtrij bereikt.<\/p>\n<p>Hieruit blijkt het belangrijkste doel van het algoritme: aangezien het algoritme niet<br \/>\nweet of een taak lang of kort is, neemt het eerst aan dat de taak<br \/>\nkort is en geeft deze de hoogste prioriteit. Als dit inderdaad een korte taak is, zal<br \/>\nze snel worden uitgevoerd; anders, als het een lange taak is, zal ze langzaam afdalen<br \/>\nin prioriteit en zal spoedig bewijzen dat het inderdaad een langdurige taak is, die geen<br \/>\nrespons vereist.<\/p>\n<p><b>Voorbeeld 3: Wat betreft invoer en uitvoer?<\/b><\/p>\n<p>Laten we nu eens kijken naar het voorbeeld met invoer en uitvoer. Zoals gesteld in regel 4b,<br \/>\nals een proces de CPU vrijgeeft zonder zijn procesortijd volledig te hebben gebruikt,<br \/>\nblijft het op hetzelfde prioriteitsniveau. De intenties van deze regel zijn vrij eenvoudig -<br \/>\nals een interactief taak veel invoer- en uitvoeroperaties uitvoert, bijvoorbeeld terwijl het<br \/>\nwacht op toetsaanslagen of muisklikken van de gebruiker, zal zo'n taak de CPU<br \/>\neerder vrijgeven dan het toegekende venster. We willen deze taak niet verlagen in prioriteit,<br \/>\nen zo blijft deze op hetzelfde niveau.<br \/>\n<img decoding=\"async\" alt=\"Operating Systems: Three Easy Pieces. Deel 5: Planning: Multi-Level Feedback Queue (vertaling).\" src=\"\/wp-content\/uploads\/2019\/04\/480d33a670fb62a639e5938dd59e30a1.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Dit voorbeeld laat zien hoe het algoritme werkt met dergelijke processen - interactief taak B, dat alleen 1 ms CPU nodig heeft voordat het<br \/>\nde invoer-uitvoersprocessen uitvoert, en langdurige taak A, die al zijn tijd aan CPU besteedt.<br \/>\nMLFQ houdt proces B op de hoogste prioriteit, omdat het continu de<br \/>\nCPU vrijgeeft. Als B een interactief taak is, dan heeft het algoritme in dat geval zijn<br \/>\ndoel bereikt door interactieve taken snel te starten.<\/p>\n<p><b>Problemen met het huidige MLFQ-algoritme<\/b><\/p>\n<p>In de voorgaande voorbeelden hebben we een basisversie van MLFQ gebouwd. En het lijkt erop dat het<br \/>\nzijn werk goed en eerlijk doet door processortijd eerlijk te verdelen tussen<br \/>\nlangdurige taken en snelle of invoer-intensieve taken snel te laten draaien. Helaas bevat deze aanpak verschillende<br \/>\nmoet snel reageren op input-output. Helaas bevat deze aanpak verschillende<br \/>\nernstige problemen.<br \/>\n<b>Firstly<\/b>, het probleem van honger: als er veel interactieve<br \/>\ntaken in het systeem zijn, zullen ze al het CPU-tijd verbruiken en kan geen enkele lange<br \/>\ntaak uitgevoerd worden (ze lijden honger).<\/p>\n<p><b>Secondly<\/b>, slimme gebruikers zouden hun programma's zo kunnen schrijven dat<br \/>\nze de planner kunnen misleiden. De truc is om iets te doen dat ervoor zorgt dat<br \/>\nde planner de taak meer CPU-tijd toekent. Het algoritme dat<br \/>\nhierboven is beschreven is vrij kwetsbaar voor dergelijke aanvallen: voordat het tijdvenster bijna<br \/>\nis afgelopen, moet een invoer-output operatie worden uitgevoerd (met een, maakt niet uit welke, bestand)<br \/>\nen zo de CPU vrijmaken. Dergelijk gedrag zal ervoor zorgen dat men in dezelfde<br \/>\nwachtrij blijft en weer een groter percentage CPU-tijd ontvangt. Als je dit<br \/>\nop de juiste manier doet (bijvoorbeeld 99% van de tijd in het venster voor het vrijgeven van CPU),<br \/>\nkan zo'n taak eenvoudigweg de processor monopoliseren.<\/p>\n<p>Ten slotte kan een programma zijn gedrag in de loop van de tijd veranderen. De taken,<br \/>\ndie CPU gebruikten, kunnen interactief worden. In ons voorbeeld zouden dergelijke<br \/>\ntaken niet goed worden behandeld door de planner, omdat ze andere<br \/>\n(oorspronkelijke) interactieve taken zouden hebben gekregen.<\/p>\n<p><u>Vraag aan de zaal: welke aanvallen op de planner konden in de moderne wereld worden uitgevoerd?<br \/>\n<\/u><\/p>\n<h4>Poging 2: Prioriteit verhogen<\/h4>\n<p>Laten we proberen de regels te veranderen en kijken of we de problemen met<br \/>\nhonger kunnen vermijden. Wat kunnen we doen om te garanderen dat gerelateerde<br \/>\nCPU-taken hun tijd krijgen (ook al is het niet lang).<br \/>\nEen eenvoudige oplossing voor het probleem zou kunnen zijn om periodiek<br \/>\nde prioriteit van al deze taken in het systeem te verhogen. Er zijn veel manieren<br \/>\nom dit te bereiken, laten we als voorbeeld iets eenvoudigs proberen: alle<br \/>\ntaken onmiddellijk naar de hoogste prioriteit te vertalen, vandaar de nieuwe regel:<\/p>\n<ul>\n<li><b>Regel5<\/b>: Na een bepaalde periode S alle taken in het systeem naar de hoogste wachtrij te verplaatsen.<\/li>\n<\/ul>\n<p>Onze nieuwe regel lost twee problemen tegelijk op. Ten eerste, processen<br \/>\nlijden gegarandeerd geen honger: taken die zich in de hoogste wachtrij bevinden zullen het<br \/>\nCPU-tijd delen volgens het RR-algoritme en zo zullen alle processen krijgen<br \/>\nverwerktijd. Ten eerste, als een proces dat eerder alleen de CPU gebruikte<br \/>\ninteractief wordt, blijft het in de wachtrij met een hogere prioriteit<br \/>\nnadat het eenmaal een prioriteitsverhoging naar de hoogste heeft gekregen.<br \/>\nLaten we een voorbeeld bekijken. In dit scenario bekijken we \u00e9\u00e9n proces dat<br \/>\n<img decoding=\"async\" alt=\"Operating Systems: Three Easy Pieces. Deel 5: Planning: Multi-Level Feedback Queue (vertaling).\" src=\"\/wp-content\/uploads\/2019\/04\/3b8d879ab4479622684b126ec5af6af3.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>CPU gebruikt en twee interactieve, korte processen. Links in de afbeelding toont het beeld het gedrag zonder prioriteitsverhoging, en zo begint de lange taak te verhongeren na de komst van de twee interactieve taken in het systeem. In de afbeelding rechts vindt elke 50 ms een prioriteitsverhoging plaats, zodat alle processen gegarandeerd CPU-tijd krijgen en periodiek worden uitgevoerd. 50 ms is in dit geval ter illustratie genomen, in werkelijkheid is dit aantal iets hoger.<br \/>\nHet is duidelijk dat de toevoeging van de tijd voor periodieke verhoging S leidt tot<br \/>\nde relevante vraag: welke waarde moet worden ingesteld? Een van de gerespecteerde<br \/>\nsysteemingenieurs, John Ousterhout, noemde dergelijke grootheden in systemen voo-doo<br \/>\nconstanten, omdat ze op een bepaalde manier een soort zwarte magie vereisten voor de correcte<br \/>\ninstelling. En helaas heeft S die geur. Als de waarde te hoog wordt ingesteld,<br \/>\nbeginnen lange taken te verhongeren. En als de waarde te laag is ingesteld,<br \/>\nkrijgen interactieve taken niet voldoende CPU-tijd.<\/p>\n<h4>Poging 3: Betere tijdregistratie<\/h4>\n<p>Nu hebben we nog een probleem dat moet worden opgelost: hoe voorkomen<br \/>\nwe dat onze planner wordt bedrogen? De schuldigen aan deze mogelijkheid zijn<br \/>\nregels 4a, 4b, die het mogelijk maken dat een taak zijn prioriteit behoudt door de CPU<br \/>\nvrij te geven voordat de toegewezen tijd is verstreken. Hoe gaan we hiermee om?<br \/>\nDe oplossing in dit geval kan worden beschouwd als een betere registratie van de CPU-tijd op elk<br \/>\nniveau van MLFQ. In plaats van de tijd te vergeten die het programma heeft gebruikt<br \/>\nvoor de toegewezen periode, moet deze worden genoteerd en behouden. Nadat<br \/>\neen proces zijn toegewezen tijd heeft verbruikt, moet het naar het volgende<br \/>\nprioriteitsniveau worden verlaagd. Het maakt nu niet uit hoe het proces zijn tijd gebruikt \u2014 of<br \/>\nconstant berekeningen uitvoerend op de CPU of door meerdere aanroepen. Dus,<br \/>\nregel 4 moet als volgt worden herschreven:<\/p>\n<ul>\n<li><b>Regel4<\/b>: Nadat een taak de toegewezen tijd in de huidige wachtrij heeft verbruikt (ongeacht hoe vaak deze de CPU heeft vrijgegeven), wordt de prioriteit van die taak verlaagd (deze beweegt omlaag in de wachtrij).<\/li>\n<\/ul>\n<p>Laten we een voorbeeld bekijken:<br \/>\n<img decoding=\"async\" alt=\"Operating Systems: Three Easy Pieces. Deel 5: Planning: Multi-Level Feedback Queue (vertaling).\" src=\"\/wp-content\/uploads\/2019\/04\/18c53e62b9b342d14a23995bd422ef5e.png\" style=\"display:block;margin: 0 auto;\">&gt;<\/p>\n<p>In de afbeelding wordt getoond wat er gebeurt als je de planner probeert te bedriegen, zoals<br \/>\nals het was met de vorige regels 4a, 4b, dan krijg je het resultaat aan de linkerkant. Met de nieuwe<br \/>\nregel \u2014 het resultaat rechts. Voor de bescherming kon elk proces I\/O aanroepen tot het was voltooid en<br \/>\nkon het zo de CPU domineren, na de inschakeling van de bescherming, ongeacht het gedrag<br \/>\nvan de I\/O, zal het nog steeds omlaag in de wachtrijen gaan en zal het dus de CPU-resources niet onterecht<br \/>\nkunnen verwerven.<\/p>\n<h4>Verbetering van MLFQ en andere problemen<\/h4>\n<p>Met de bovengenoemde verbeteringen ontstaan nieuwe problemen: een van de belangrijkste<br \/>\nvragen is \u2014 hoe deze planner te parametriseren? Dat wil zeggen, hoeveel zouden er moeten zijn<br \/>\nwachtrijen? Wat moet de grootte van het werkvenster binnen de wachtrij zijn? Hoe<br \/>\nvaak moet de prioriteit van een programma worden verhoogd om hongerigheid te voorkomen en<br \/>\nrekening te houden met veranderend gedrag van het programma? Voor deze vragen is er geen eenvoudig<br \/>\nantwoord en alleen experimenten met belastingen en daaropvolgende configuratie<br \/>\nvan de planner kunnen leiden tot een zekere bevredigende balans.<\/p>\n<p>Bijvoorbeeld, de meeste implementaties van MLFQ staan verschillende<br \/>\ntijdduren toe voor verschillende wachtrijen. Hoogprioritaire wachtrijen krijgen meestal<br \/>\nkorte intervallen. Deze wachtrijen bestaan uit interactieve taken,<br \/>\nwaarbij het wisselen tussen hen vrij gevoelig is en 10 ms of minder moet duren.<br \/>\nIn tegenstelling tot laagprioritaire wachtrijen, die bestaan uit lange taken die gebruikmaken van<br \/>\nde CPU. En in dit geval zijn lange tijdduren zeer geschikt (100 ms).<br \/>\n<img decoding=\"async\" alt=\"Operating Systems: Three Easy Pieces. Deel 5: Planning: Multi-Level Feedback Queue (vertaling).\" src=\"\/wp-content\/uploads\/2019\/04\/4eb6c6669034adeb1615c29454fbb1dc.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>In dit voorbeeld zijn er 2 taken die 20 ms in de hoogprioritaire wachtrij hebben gewerkt, verdeeld in vensters van 10 ms. 40 ms in de gemiddelde wachtrij (venster van 20 ms) en in de laagprioritaire<br \/>\nwachtrij was het tijdvenster 40 ms, waar de taken hun werk voltooide.<br \/>\nDe implementatie van MLFQ in het Solaris-besturingssysteem - een klasse van planningsalgoritmes die in de tijd splitsen.<\/p>\n<p>De planner biedt een set tabellen die precies defini\u00ebren hoe de prioriteit van een proces moet<br \/>\nveranderen gedurende zijn levensduur, wat de grootte moet zijn.<br \/>\nprioriteit van het proces kan veranderen gedurende zijn levenscyclus, wat de juiste omvang moet zijn<br \/>\nvan het toegewezen venster en hoe vaak prioriteiten voor taken moeten worden verhoogd. De administrator<br \/>\nvan het systeem kan interactie hebben met deze tabel en de planner dwingen zich<br \/>\nanders te gedragen. Standaard heeft deze tabel 60 wachtrijen met een geleidelijke verhoging<br \/>\nvan de venstergrootte van 20 ms (hoge prioriteit) tot enkele honderden ms (lage prioriteit), en<br \/>\nook een boost voor alle taken eenmaal per seconde.<\/p>\n<p>Andere MLFQ-planners gebruiken geen tabel of specifieke<br \/>\nregels die in deze lezing zijn beschreven, in plaats daarvan berekenen ze prioriteiten met behulp van<br \/>\nwiskundige formules. Zo gebruikt de planner in FreeBSD een formule om<br \/>\nde huidige prioriteit van een taak te berekenen, gebaseerd op hoeveel de processor<br \/>\nde CPU heeft gebruikt. Bovendien vergaat het CPU-gebruik in de loop van de tijd, en op die manier<br \/>\nvindt prioriteitsverhoging iets anders plaats dan hierboven beschreven. Dit zijn de<br \/>\nzogenaamde decay-algoritmen. Sinds versie 7.1 gebruikt FreeBSD de ULE-planner.<\/p>\n<p>Ten slotte hebben veel planners andere kenmerken. Bijvoorbeeld, sommige<br \/>\nplanners reserveren de hoogste niveaus voor het werk van het besturingssysteem, zodat<br \/>\ngeen enkele gebruikersproces de hoogste prioriteit in<br \/>\nhet systeem kan krijgen. Sommige systemen staan toe om adviezen te geven om de planner<br \/>\nte helpen prioriteiten correct in te stellen. Zo kan men bijvoorbeeld met het commando <b>nice<\/b><br \/>\nde prioriteit van een taak verhogen of verlagen, en zo de kansen van het programma op CPU-tijd verhogen of<br \/>\nverlagen.<\/p>\n<h3>MLFQ: Samenvatting<\/h3>\n<p>We hebben een planningsaanpak beschreven die MLFQ wordt genoemd. De naam<br \/>\nheeft te maken met de werking ervan \u2014 het heeft meerdere wachtrijen en gebruikt feedback<br \/>\nom de prioriteit van taken te bepalen.<br \/>\nDe uiteindelijke set regels is als volgt:<\/p>\n<ul>\n<li><b>Regel1<\/b>: Als prioriteit(A) &gt; Prioriteit(B), zal taak A worden uitgevoerd (B niet)<\/li>\n<li><b>Regel2<\/b>: Als prioriteit(A) = Prioriteit(B), worden A en B uitgevoerd met behulp van RR<\/li>\n<li><b>Regel3<\/b>: Wanneer een taak het systeem binnenkomt, wordt deze in de wachtrij met de hoogste prioriteit geplaatst.<\/li>\n<li><b>Regel4<\/b>: Nadat een taak de toegewezen tijd in de huidige wachtrij heeft verbruikt (ongeacht hoe vaak deze de CPU heeft vrijgegeven), wordt de prioriteit van die taak verlaagd (deze beweegt omlaag in de wachtrij).<\/li>\n<li><b>Regel5<\/b>: Na een bepaalde periode S alle taken in het systeem naar de hoogste wachtrij te verplaatsen.<\/li>\n<\/ul>\n<p>MLFQ is interessant om de volgende reden \u2014 in plaats van vooraf kennis te vereisen over<br \/>\nde aard van de taak, leert het algoritme van het eerder gedrag van de taak en stelt het in.<br \/>\nde prioriteiten dienovereenkomstig. Zo probeert hij tegelijkertijd op twee stoelen te zitten \u2014 prestaties te behalen voor kleine taken (SJF, STCF) en eerlijk grote,<br \/>\nCPU-belastende taken te verwerken. Daarom gebruiken veel systemen, waaronder BSD en hun afgeleiden,<br \/>\nSolaris, Windows, Mac een bepaalde vorm van algoritme<br \/>\nMLFQ als basis.<\/p>\n<h4>Extra materialen:<\/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.nl.html<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Scheduling_\">nl.wikipedia.org\/wiki\/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>Bron: <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.3 - 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\/nl\/blog\/administrirovanie\/operating-systems-three-easy-pieces-part-5-planirovanie-multi-level-feedback-queue-perevod\" \/>\n\t\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.3\" \/>\n\t\t<meta property=\"og:locale\" content=\"nl_NL\" \/>\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\/nl\/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\udd47Besturingssystemen: Drie Gemakkelijke Stukken. Deel 5: Plannen: Multi-Level Feedback Queue (vertaling) | ProHoster","description":"Inleiding tot besturingssystemen Hallo, Habr! Ik wil jullie graag een serie vertaalde artikelen voorstellen van een literatuur die ik interessant vind \u2014 OSTEP.","canonical_url":"https:\/\/prohoster.info\/nl\/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":"nl_NL","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\/nl\/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\/nl\/wp-json\/wp\/v2\/posts\/32730","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/comments?post=32730"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/posts\/32730\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media\/24514"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/media?parent=32730"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/categories?post=32730"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/nl\/wp-json\/wp\/v2\/tags?post=32730"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}