{"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\/sl\/blog\/administrirovanie\/operating-systems-three-easy-pieces-part-5-planirovanie-multi-level-feedback-queue-perevod","title":{"rendered":"Operativni sistemi: Tri laka dela. Deo 5: Planiranje: Vi\u0161eslojna povratna informacija (prevod)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<h1>Uvod v operacijske sisteme<\/h1>\n<p>Pozdravljeni, Habr! \u017delim vam predstaviti serijo prevodnih \u010dlankov, ki se mi zdijo zanimivi \u2014 OSTEP. V tem gradivu se poglobljeno obravnava delovanje unix-podobnih operacijskih sistemov, in sicer obravnava procesov, razli\u010dnih pojedin\u0161kov, pomnilnika in ostalih podobnih komponent, ki sestavljajo sodobni OS. Izvirnik vseh gradiv si lahko ogledate tukaj. <noindex><a rel=\"nofollow\" href=\"http:\/\/pages.cs.wisc.edu\/~remzi\/OSTEP\/\">tukaj<\/a><\/noindex>. Prosimo, upo\u0161tevajte, da je prevod izveden nepoklicno (dokaj prosto), a upam, da sem ohranil splo\u0161en smisel.<\/p>\n<p>Laboratorijske vaje za to temo lahko najdete tukaj:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"http:\/\/pages.cs.wisc.edu\/~remzi\/OSTEP\/Homework\/homework.html\">izvirnik<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/remzi-arpacidusseau\/ostep-code\">izvirnik<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/bykvaadm\/OS\/tree\/master\/ostep\">moja osebna prilagoditev<\/a><\/noindex><\/li>\n<\/ul>\n<p>Druge dele:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/446340\/\">Del 1: Uvod<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/446866\/\">Del 2: Abstrakcija: proces<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/447182\/\">Del 3: Uvod v API procesov<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/449026\/\">Del 4: Uvod v na\u010drtovalnik<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/450116\/\">Del 5: MLFQ Scheduler<\/a><\/noindex><\/li>\n<\/ul>\n<p>Lahko tudi obi\u0161\u010dete moj kanal v <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>Planificaci\u00f3n: Cola de Realimentaci\u00f3n Multinivel<\/h2>\n<p>En esta lecci\u00f3n, hablaremos sobre los problemas de desarrollar uno de los enfoques m\u00e1s conocidos para<br \/>\nla planificaci\u00f3n, que se llama <b>Cola de Realimentaci\u00f3n Multinivel<\/b> (MLFQ). Por primera vez, el planificador MLFQ fue descrito en 1962 por Fernando J. Corbat\u00f3 en un sistema llamado<br \/>\nCompatible Time-Sharing System (CTSS). Estos trabajos (incluyendo trabajos posteriores sobre<br \/>\nMultics) fueron posteriormente presentados para el premio Turing. El planificador fue<br \/>\nmejorado posteriormente y adquiri\u00f3 una forma que se puede encontrar en<br \/>\nalgunos sistemas modernos.<\/p>\n<p>El algoritmo MLFQ intenta resolver 2 problemas fundamentales interrelacionados.<br \/>\n<b>Najprej,<\/b>, intenta optimizar el tiempo de rotaci\u00f3n, que, como discutimos en la lecci\u00f3n anterior, se optimiza ejecutando al principio la cola las m\u00e1s<br \/>\ncortas tareas. Sin embargo, el SO no sabe cu\u00e1nto tiempo va a funcionar un proceso determinado, y ese es<br \/>\nun conocimiento necesario para que funcionen los algoritmos SJF, STCF. <b>Drugi\u010d<\/b>, MLFQ intenta<br \/>\nhacer que el sistema sea receptivo para los usuarios (por ejemplo, para aquellos que est\u00e1n sentados y<br \/>\nmirando la pantalla en espera de que se complete una tarea) y as\u00ed minimizar el tiempo<br \/>\nde respuesta. Desafortunadamente, algoritmos como RR reducen el tiempo de respuesta, pero tienen un impacto muy<br \/>\nnegativo en la m\u00e9trica del tiempo de rotaci\u00f3n. De ah\u00ed nuestra pregunta: \u00bfC\u00f3mo dise\u00f1ar<br \/>\nun planificador que satisfaga nuestros requisitos y al mismo tiempo no sepa nada sobre<br \/>\nla naturaleza del proceso en general? \u00bfC\u00f3mo puede un planificador aprender sobre las caracter\u00edsticas de las tareas,<br \/>\nque ejecuta y as\u00ed tomar mejores decisiones de planificaci\u00f3n?<\/p>\n<p><u>La esencia del problema: \u00bfC\u00f3mo planificar la puesta en marcha de tareas sin un conocimiento ideal?<br \/>\n\u00bfC\u00f3mo desarrollar un planificador que minimice al mismo tiempo el tiempo de respuesta<br \/>\npara tareas interactivas, mientras minimiza el tiempo de rotaci\u00f3n sin un conocimiento previo<br \/>\ndel tiempo de ejecuci\u00f3n de la tarea?<\/u><\/p>\n<p>Nota: aprendemos de eventos pasados<\/p>\n<p>La cola MLFQ es un gran ejemplo de un sistema que se entrena sobre<br \/>\neventos pasados para predecir el futuro. Enfoques similares son comunes<br \/>\nen los SO (y en muchas otras \u00e1reas de la inform\u00e1tica, incluyendo ramas de<br \/>\npredicci\u00f3n en hardware y algoritmos de cach\u00e9). Estos enfoques<br \/>\nfuncionan cuando las tareas tienen fases comportamentales y, por lo tanto, son predecibles.<br \/>\nVendar pa je s to tehniko treba biti previden, ker so napovedi zelo lahko<br \/>\nnepravilne in lahko pripeljejo sistem do sprejemanja slab\u0161ih odlo\u010ditev, kot bi<br \/>\nbile brez znanja na splo\u0161no.<\/p>\n<h3>MLFQ: Osnovna pravila<\/h3>\n<p>Poglejmo osnovna pravila algoritma MLFQ. \u010ceprav obstaja ve\u010d implementacij tega algoritma,<br \/>\nso osnovni pristopi podobni.<br \/>\nV tisti implementaciji, ki jo bomo obravnavali, bo MLFQ imel ve\u010d<br \/>\nlo\u010denih vrstic, vsaka z razli\u010dnimi prioritetami. Kadarkoli,<br \/>\nnaloga, pripravljena za izvajanje, se nahaja v eni od vrstic. MLFQ uporablja prioritete,<br \/>\nda odlo\u010di, katero nalogo izvajati, t.j. naloga z vi\u0161jo<br \/>\nprioriteto (naloga iz vrste z najvi\u0161jo prioritetno) bo najprej zagnana.<br \/>\nNedvomno lahko v specifi\u010dni vrsti obstaja ve\u010d nalog, tako<br \/>\nda bodo imele enako prioriteto. V tem primeru se bo uporabil mehanizem<br \/>\nRR za na\u010drtovanje izvajanja med temi nalogami.<br \/>\nTako pridemo do dveh osnovnih pravil za MLFQ:<br \/>\nPravilo 1: \u010ce je prioriteta(A) &gt; Prioriteta(B), bo zagnana naloga A (B ne bo)<\/p>\n<ul>\n<li> Pravilo 2: \u010ce je prioriteta(A) = Prioriteta(B), A in B se izvajata z uporabo RR<\/li>\n<li> Glede na zgoraj navedeno so klju\u010dni elementi pri na\u010drtovanju MLFQ<\/li>\n<\/ul>\n<p>prioritete. Namesto da bi vsakemu<br \/>\nnalogu dodelili fiksno prioriteto, MLFQ spreminja njeno prioriteto glede na opazovano vedenje.<br \/>\nNa primer, \u010de naloga nenehno prekinja delo na CPU-ju med \u010dakanjem na vhod s tipkovnice,<br \/>\nbo MLFQ ohranjal prioriteto procesa na visoki ravni, ker tako<br \/>\nmora delovati interaktiven proces. \u010ce pa naloga nenehno in<br \/>\nintenzivno uporablja CPU v dalj\u0161em obdobju, bo MLFQ zni\u017eal njeno<br \/>\nprioriteto. Tako bo MLFQ preu\u010deval vedenje procesov med njihovo izvedbo<br \/>\nin uporabljal to vedenje.<br \/>\nNari\u0161imo primer, kako bi lahko videle vrste v nekem trenutku<br \/>\nin potem bo to izgledalo nekako takole:<br \/>\nV tej shemi sta dva procesa A in B v vrsti z najvi\u0161jo prioriteto. Postopek<br \/>\n<img decoding=\"async\" alt=\"Operativni sistemi: Tri laka dela. Deo 5: Planiranje: Vi\u0161eslojna povratna informacija (prevod)\" src=\"\/wp-content\/uploads\/2019\/04\/3598e9ca43a56049625bdcf3074de472.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>C je nekje na sredini, postopek D pa na koncu vrste. V skladu s prej\u0161njimi<br \/>\nopisi algoritma MLFQ bo na\u010drtovalec izvajal naloge samo z najvi\u0161jo<br \/>\nprednostjo.<br \/>\nprioritetom v skladu z RR, medtem ko bosta nalogi C in D brez dela.<br \/>\nSeveda stati\u010dni posnetek ne bo dal celotne slike, kako deluje MLFQ.<br \/>\nPomembno je razumeti, kako se slika spreminja s \u010dasom.<\/p>\n<h4>Poskus 1: Kako spreminjati prioriteto<\/h4>\n<p>V tem trenutku je potrebno odlo\u010diti, kako bo MLFQ spreminjal raven prioritete<br \/>\nnalog (in tako mesto naloge v vrsti) v poteku njenega \u017eivljenjskega cikla. Za<br \/>\nto je potrebno imeti v mislih delovni proces: dolo\u010deno \u0161tevilo<br \/>\ninteraktivnih nalog s kratkim \u010dasom delovanja (in tako pogostim osvoboditvijo<br \/>\nCPU) in nekaj dolgih nalog, ki uporabljajo CPU ves svoj delovni \u010das, pri tem pa<br \/>\n\u010dasa odziva za take naloge ni pomembno. Tako lahko naredimo prvi poskus<br \/>\nizvesti algoritem MLFQ s naslednjimi pravili:<\/p>\n<ul>\n<li> Pravilnik 3: Ko naloga prispe v sistem, je postavljena v vrsto z najvi\u0161jim<\/li>\n<li>prioriteto.<\/li>\n<li>Pravilnik 4a: \u010ce naloga v celoti izkoristi dodeljen \u010dasovni okvir, se njen<\/li>\n<li>prioritet zni\u017ea.<\/li>\n<li>Pravilnik 4b: \u010ce naloga osvobodi CPU pred iztekom svojega \u010dasovnega okvirja, tako ostane<\/li>\n<li>z istim prioritetom.<\/li>\n<\/ul>\n<p><b>Primer 1: Edina dolgotrajna naloga<\/b><\/p>\n<p>Kot je razvidno v tem primeru, naloga pride na najvi\u0161ji<br \/>\nprioritet. Po \u010dasovnem okviru 10 ms se proces zni\u017ea v prioriteto<br \/>\ns strani na\u010drtovalnika. Po naslednjem \u010dasovnem okviru se naloga kon\u010dno zni\u017ea do<br \/>\nnajni\u017eje prioritete v sistemu, kjer ostane.<br \/>\n<img decoding=\"async\" alt=\"Operativni sistemi: Tri laka dela. Deo 5: Planiranje: Vi\u0161eslojna povratna informacija (prevod)\" src=\"\/wp-content\/uploads\/2019\/04\/9b4ee6de03aa92d7957d50b4ffa73949.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p><b>Primer 2: Pripeljali kratko nalogo<\/b><\/p>\n<p>Zdaj poglejmo primer, kako se MLFQ posku\u0161a pribli\u017eati SJF. V tem<br \/>\nprimeru sta dve nalogi: A, ki je dolgotrajna naloga, ki nenehno<br \/>\nzaseda CPU, in B, ki je kratka interaktivna naloga. Predpostavimo,<br \/>\nda je A \u017ee delala nekaj \u010dasa, ko je naloga B pri\u0161la.<br \/>\n<img decoding=\"async\" alt=\"Operativni sistemi: Tri laka dela. Deo 5: Planiranje: Vi\u0161eslojna povratna informacija (prevod)\" src=\"\/wp-content\/uploads\/2019\/04\/19c299b0519585fd1076a341a71f048b.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Na tem grafu so vidni rezultati scenarija. Naloga A, kot katerakoli naloga,<br \/>\nki uporablja CPU, je bila na samem dnu. Naloga B bo pri\u0161la ob T=100 in bo<br \/>\npostavljena v vrsto z najvi\u0161jim prioritetom. Ker je \u010das njenega delovanja kratek,<br \/>\nse bo kon\u010dala, preden dose\u017ee zadnjo vrsto.<\/p>\n<p>Iz tega primera je potrebno razumeti glavni cilj algoritma: ker algoritem ne<br \/>\nve, ali je naloga dolga ali kratka, najprej predvideva, da je naloga<br \/>\nkratka naloga in ji daje najve\u010dji prednost. \u010ce gre za res kratko nalogo,<br \/>\nbo hitro izvedena, sicer pa, \u010de gre za dolgo nalogo, se bo po\u010dasi premikala<br \/>\nni\u017eji prioriteta in kmalu bo dokazala, da je to res dolga naloga, ki ne<br \/>\nzahteva odziva.<\/p>\n<p><b>Primer 3: Kaj pa vhod-izhod?<\/b><\/p>\n<p>Poglejmo primer z vhodom-izhodom. Kot je bilo navedeno v pravilu 4b,<br \/>\n\u010de proces sprosti procesor, ne da bi v celoti izkoristil svoj \u010das procesorja,<br \/>\ntako ostaja na prej\u0161nji ravni prioritete. Namen tega pravila je razmeroma preprost<br \/>\n- \u010de interaktivna naloga izvaja veliko operacij vhod-izhod, na primer \u010daka<br \/>\nna pritiske tipk ali mi\u0161ke, se bo taka naloga prej sprostila z procesorja<br \/>\nkot dodeljenemu oknu. Ne bi \u017eeleli zni\u017eati prioritete take naloge,<br \/>\nin tako bo ostala na prej\u0161nji ravni.<br \/>\n<img decoding=\"async\" alt=\"Operativni sistemi: Tri laka dela. Deo 5: Planiranje: Vi\u0161eslojna povratna informacija (prevod)\" src=\"\/wp-content\/uploads\/2019\/04\/480d33a670fb62a639e5938dd59e30a1.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Ta primer prikazuje, kako bo algoritem deloval s takimi procesi - interaktivna naloga B, ki potrebuje CPU le 1 ms pred izvedbo<br \/>\nprocesa vhod-izhod in dolga naloga A, ki ves svoj \u010das uporablja CPU.<br \/>\nMLFQ dr\u017ei postopek B z najvi\u0161jo prioriteto, saj ves \u010das nadaljuje<br \/>\nspro\u0161\u010danje CPU. \u010ce je B interaktivna naloga, je algoritem v tem primeru dosegel<br \/>\nsvoj cilj, da hitro za\u017eene interaktivne naloge.<\/p>\n<p><b>Te\u017eave s trenutnim algoritmom MLFQ<\/b><\/p>\n<p>V prej\u0161njih primerih smo zgradili osnovno razli\u010dico MLFQ. Zdi se, da<br \/>\ndobro opravlja svoje delo in po\u0161teno dodeljuje \u010das procesorja med<br \/>\ndolgimi nalogami ter omogo\u010da kratkim nalogam ali nalogam, ki intenzivno<br \/>\npristopajo k vhodu in izhodu, da se hitro izvedejo. Na \u017ealost ta pristop vsebuje nekaj<br \/>\nresnih te\u017eav.<br \/>\n<b>Najprej,<\/b>, problem lakote: \u010de v sistemu obstaja veliko interaktivnih<br \/>\nnalog, bodo odvzele ves \u010das procesorja in tako nobena dolga<br \/>\nnaloga ne bo imela mo\u017enosti izvajanja (torej strada).<\/p>\n<p><b>Drugi\u010d<\/b>, pametni uporabniki bi lahko pisali svoje programe tako, da<br \/>\nprevarajo na\u010drtovalnik. Prevara je v tem, da storijo nekaj takega, da<br \/>\nprisilijo na\u010drtovalnik, da dodeli procesu ve\u010d \u010dasa procesorja. Algoritem, ki<br \/>\nopisano zgoraj je povsem ranljivo za take napade: preden se \u010dasovno okno prakti\u010dno<br \/>\nkon\u010da, je treba izvesti operacijo vnosa-izvoda (na nek datoteko, ni pomembno katero)<br \/>\nin na ta na\u010din osvoboditi CPU. Tak\u0161no vedenje bo omogo\u010dilo ostati v isti<br \/>\nvrsti in ponovno pridobiti vi\u0161ji odstotek procesorskega \u010dasa. \u010ce to stori\u0161<br \/>\nprav (na primer, izvajati 99% \u010dasa okna pred osvoboditvijo CPU),<br \/>\nlahko ta naloga enostavno monopolizira procesor.<\/p>\n<p>Nazadnje, program lahko s\u010dasoma spreminja svoje vedenje. Tiste naloge,<br \/>\nki so uporabljale CPU, lahko postanejo interaktivne. V na\u0161em primeru podobne<br \/>\nnaloge ne bodo prejele ustrezne obravnave s strani plannerja, kot bi prejele druge<br \/>\n(prvotne) interaktivne naloge.<\/p>\n<p><u>Vpra\u0161anje za ob\u010dinstvo: katere napade na plannerja je mogo\u010de storiti v sodobnem svetu?<br \/>\n<\/u><\/p>\n<h4>Poskus 2: Povi\u0161anje prioritete<\/h4>\n<p>Poskusimo spremeniti pravila in poglejmo, ali lahko uspemo prepre\u010diti te\u017eave z<br \/>\nlakoto. Kaj bi mogli storiti, da zagotovimo, da povezane z<br \/>\nCPU naloge dobijo svoj \u010das (tudi \u010de ne dolgo).<br \/>\nKot enostavno re\u0161itev problema lahko predlagamo, da ob\u010dasno<br \/>\npovi\u0161amo prioriteto vseh takih nalog v sistemu. Obstaja ve\u010d na\u010dinov<br \/>\nza dosego tega, poskusimo uresni\u010diti nekaj preprostega: prenesti<br \/>\nvse naloge takoj v najvi\u0161jo prioriteto, od tu novo pravilo:<\/p>\n<ul>\n<li><b>Rule5<\/b>: Po preteku nekega obdobja S prenesi vse naloge v sistemu v najvi\u0161jo vrsto.<\/li>\n<\/ul>\n<p>Na\u0161e novo pravilo re\u0161uje dva problema hkrati. Prvi\u010d, procesi<br \/>\nso zagotovljeno brez lakote: naloge, ki so v najvi\u0161ji vrsti, bodo delili<br \/>\nprocesorsko \u010dasovno obdobje po algoritmu RR in tako bodo vsi procesi dobili<br \/>\nprocesorsko \u010dasovno obdobje. Drugi\u010d, \u010de kateri koli proces, ki je prej uporabljal<br \/>\nsamo procesor, postane interaktiven, bo ostal v vrsti z vi\u0161jo<br \/>\nprioriteto potem, ko enkrat dobi povi\u0161anje prioritete na najvi\u0161jo.<br \/>\nRazmislimo o primeru. V tem scenariju razmislimo o enem procesu, ki uporablja<br \/>\n<img decoding=\"async\" alt=\"Operativni sistemi: Tri laka dela. Deo 5: Planiranje: Vi\u0161eslojna povratna informacija (prevod)\" src=\"\/wp-content\/uploads\/2019\/04\/3b8d879ab4479622684b126ec5af6af3.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>CPU in dva interaktivna, kratka procesa. Na levi sliki prikazuje vedenje brez pove\u010danja prioritet, tako da dolga naloga za\u010dne stradati po prihodu dveh interaktivnih nalog v sistem. Na desni sliki se vsake 50 ms izvede pove\u010danje prioritet, tako da vse naloge zagotovo dobijo \u010das procesorja in se bodo ob\u010dasno zagnale. 50 ms je v tem primeru vzeto kot primer, dejansko je to \u0161tevilo nekoliko ve\u010dje.<br \/>\nO\u010ditno je, da dodajanje \u010dasa periodi\u010dnega pove\u010danja S prina\u0161a<br \/>\nlogi\u010dno vpra\u0161anje: kak\u0161na vrednost bi morala biti nastavljena? Eden od uglednih<br \/>\nsistemskih in\u017eenirjev John Ousterhout je tak\u0161ne vrednosti v sistemih imenoval voo-doo<br \/>\nkonstanta, saj so v nekem smislu zahtevale \u010darovnijo za pravilno<br \/>\nnastavitev. In, na \u017ealost, S ima tak aromo. \u010ce nastavite vrednost preveliko,<br \/>\ndolge naloge za\u010dnejo stradati. In \u010de nastavite premajhno vrednost,<br \/>\ninteraktivne naloge ne bodo prejele zadostnega \u010dasa procesorja.<\/p>\n<h4>Poskus 3: Bolj\u0161a evidenca<\/h4>\n<p>Zdaj imamo \u0161e en problem, ki ga je treba re\u0161iti: kako<br \/>\nne dopustiti naj na\u0161a na\u010drtovalec vara? Krivci za to mo\u017enost so<br \/>\npravila 4a, 4b, ki nalogi omogo\u010dajo ohranitev prioritet, spro\u0161\u010dajo\u010d procesor<br \/>\npred iztekom dodeljenega \u010dasa. Kako se s tem spopasti?<br \/>\nRe\u0161itev v tem primeru je lahko bolj\u0161a evidenca \u010dasa CPU na vsakem<br \/>\nravni MLFQ. Namesto da pozabimo \u010das, ki ga je program uporabil<br \/>\nprocesor v dodeljenem obdobju, ga je treba upo\u0161tevati in shraniti. Potem ko<br \/>\nproces porabi dodeljeni \u010das, je treba zni\u017eati njegov prioritet na naslednjo<br \/>\nravni prioritet. Zdaj ni pomembno, kako bo proces uporabljal svoj \u010das \u2013 ali<br \/>\nneprekinjeno izra\u010dunava na procesorju ali kot ve\u010d klicev. Tako je<br \/>\npravilo 4 treba prepisati na naslednji na\u010din:<\/p>\n<ul>\n<li><b>Rule4<\/b>: Ko naloga porabi dodeljeni \u010das v trenutni vrsti (ne glede na to, koliko krat je sprostila CPU), se prioriteta take naloge zni\u017ea (premika se navzdol v vrsti).<\/li>\n<\/ul>\n<p>Poglejmo primer:<br \/>\n<img decoding=\"async\" alt=\"Operativni sistemi: Tri laka dela. Deo 5: Planiranje: Vi\u0161eslojna povratna informacija (prevod)\" src=\"\/wp-content\/uploads\/2019\/04\/18c53e62b9b342d14a23995bd422ef5e.png\" style=\"display:block;margin: 0 auto;\">\u00bb<\/p>\n<p>Na sliki je prikazano, kaj se zgodi, \u010de posku\u0161ate prevarati na\u010drtovalec, kako<br \/>\n\u010de bi imeli prej\u0161nje pravila 4a, 4b, bi dobili rezultat na levi. Z novim<br \/>\npravili \u2014 rezultat na desni. Pred za\u0161\u010dito je lahko vsak postopek povzro\u010dil I\/O pred dokon\u010danjem in<br \/>\ntako dominiral na CPU, po vklopu za\u0161\u010dite, ne glede na vedenje<br \/>\nI\/O, bo \u0161e vedno potisnjen v vrste navzdol in tako ne bo mogel nepo\u0161teno<br \/>\nprevzeti virov CPU.<\/p>\n<h4>Izbolj\u0161ujemo MLFQ in druge te\u017eave<\/h4>\n<p>Z zgoraj omenjenimi izbolj\u0161avami se pojavljajo nove te\u017eave: eno od glavnih<br \/>\nvpra\u0161anj je, kako parametrize ta na\u010drtovalnik? T.j. Koliko mora biti<br \/>\nvrst? Kak\u0161na naj bo velikost okna dela programa znotraj vrste? Kako<br \/>\npogosto je treba zvi\u0161ati prioriteto programa, da bi se izognili lakotnosti in<br \/>\nupo\u0161tevali spremembno vedenje programa? Na ta vpra\u0161anja ni preprostega<br \/>\nodgovora in le eksperimenti z obremenitvami in nato konfiguracija<br \/>\nna\u010drtovalnika lahko pripeljejo do neke zadovoljive ravnote\u017eja.<\/p>\n<p>Na primer, ve\u010dina izvedb MLFQ omogo\u010da dodeljevanje razli\u010dnih<br \/>\n\u010dasovnih intervalov razli\u010dnim vrstam. Visoko prioritetne vrste obi\u010dajno<br \/>\ndobijo kratke intervale. Te vrste vsebujejo interaktivne naloge,<br \/>\nmed katerimi je preklapljanje precej ob\u010dutljivo in naj bi trajalo 10 ali manj<br \/>\nms. Po drugi strani nizkoprioritete vrste sestavljajo dolge naloge, ki uporabljajo<br \/>\nCPU. In v tem primeru so dolgi \u010dasovni intervali zelo primerni (100ms).<br \/>\n<img decoding=\"async\" alt=\"Operativni sistemi: Tri laka dela. Deo 5: Planiranje: Vi\u0161eslojna povratna informacija (prevod)\" src=\"\/wp-content\/uploads\/2019\/04\/4eb6c6669034adeb1615c29454fbb1dc.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>V tem primeru sta 2 nalogi delovali v visoko prioritetni vrsti 20<br \/>\nms, razdeljeni na okna po 10ms. 40ms v srednji vrsti (okno 20ms) in v nizkoprioritni<br \/>\nvrsti je \u010dasovno okno postalo 40ms, kjer so naloge zaklju\u010dile svoje delo.<\/p>\n<p>Izvedba MLFQ v operacijskem sistemu Solaris \u2014 razred na\u010drtovalnikov, ki delijo \u010das.<br \/>\nNa\u010drtovalnik ponuja niz tabel, ki natan\u010dno dolo\u010dajo, kako naj se<br \/>\nspremeni prioriteta postopka skozi njegovo \u017eivljenje, kak\u0161na naj bo velikost<br \/>\ndodeljenega okna in kako pogosto je treba dvigniti prioritete naloge. Administrator<br \/>\nsistema lahko sodeluje s to tabelo in prisili na\u010drtovalnik, da se obna\u0161a<br \/>\ndruga\u010de. Privzeto ta tabela vsebuje 60 vrst z postopnim pove\u010devanjem<br \/>\nvelikosti okna od 20ms (visoka prioriteta) do ve\u010d sto ms (nizka prioriteta), ter<br \/>\ntudi z izbolj\u0161anjem vseh nalog na sekundo.<\/p>\n<p>Drugi MLFQ na\u010drtovalniki ne uporabljajo tabele ali kak\u0161nih drugih<br \/>\npravil, ki so opisana v tej predavanju; nasprotno, izra\u010dunavajo prioritete z uporabo<br \/>\nmatemati\u010dnih formul. Na primer, na\u010drtovalnik v FreeBSD uporablja formulo za<br \/>\nizra\u010dun trenutne prioritete naloge, na podlagi tega, koliko proces<br \/>\nje porabil CPU. Poleg tega, uporaba CPU s \u010dasom pada, in na ta na\u010din<br \/>\nse pove\u010danje prioritete dogaja nekoliko druga\u010de, kot je opisano zgoraj. To so<br \/>\ntako imenovani decay algoritmi. Od razli\u010dice 7.1 se v FreeBSD uporablja na\u010drtovalnik ULE.<\/p>\n<p>Nazadnje, mnogi na\u010drtovalniki imajo druge posebnosti. Na primer, nekateri<br \/>\nna\u010drtovalniki rezervirajo najvi\u0161je ravni za delovanje operacijskega sistema in na ta na\u010din<br \/>\nnoben uporabni\u0161ki proces ne more dose\u010di najvi\u0161je prioritete v<br \/>\nsistemu. Nekatere sisteme omogo\u010dajo, da dajo nasvete, da bi pomagali<br \/>\nna\u010drtovalniku pravilno dolo\u010dati prioritete. Tako lahko na primer z ukazom <b>nice<\/b><br \/>\npove\u010date ali zmanj\u0161ate prioriteto naloge in tako pove\u010date ali<br \/>\nzmanj\u0161ate mo\u017enosti programa za \u010das CPU.<\/p>\n<h3>MLFQ: Zaklju\u010dki<\/h3>\n<p>Opisali smo pristop k na\u010drtovanju, ki se imenuje MLFQ. Njegovo ime<br \/>\nje skrito v na\u010delu delovanja \u2014 ima ve\u010d vrstic in uporablja povratne informacije<br \/>\nza dolo\u010danje prioritete naloge.<br \/>\nKon\u010dni videz pravil bo naslednji:<\/p>\n<ul>\n<li><b>Pravilo1<\/b>: \u010ce je prioriteta(A) &gt; Prioriteta(B), bo zagnana naloga A (B ne bo)<\/li>\n<li><b>Pravilo2<\/b>: \u010ce je prioriteta(A) = Prioriteta(B), A in B se za\u017eeneta z uporabo RR<\/li>\n<li><b>Pravilo3<\/b>: Ko naloga pride v sistem, se postavi v vrsto z najvi\u0161jo prioriteto.<\/li>\n<li><b>Rule4<\/b>: Ko naloga porabi dodeljeni \u010das v trenutni vrsti (ne glede na to, koliko krat je sprostila CPU), se prioriteta take naloge zni\u017ea (premika se navzdol v vrsti).<\/li>\n<li><b>Rule5<\/b>: Po preteku nekega obdobja S prenesi vse naloge v sistemu v najvi\u0161jo vrsto.<\/li>\n<\/ul>\n<p>MLFQ je zanimiv iz naslednjega razloga \u2014 namesto da bi zahtevajo znanje o<br \/>\nnaravi naloge vnaprej, algoritem u\u010di preteklo vedenje naloge in dolo\u010da<br \/>\nprioritete ustrezno. Tako posku\u0161a sedeti na dveh stolih \u2014 dose\u010di zmogljivost za majhne naloge (SJF, STCF) in po\u0161teno izvajati dolge,<br \/>\nobremenjujo\u010de CPU naloge. Zato mnogi sistemi, vklju\u010dno z BSD in njihovimi derivati,<br \/>\nSolaris, Windows, Mac uporabljajo kot na\u010drtovalnik neko obliko algoritma<br \/>\nMLFQ kot temeljno osnovo.<\/p>\n<h4>Dodatni materiali:<\/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.en.html<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/en.wikipedia.org\/wiki\/Scheduling_\">en.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>Izvor: <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.4 - 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\/sl\/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.4\" \/>\n\t\t<meta property=\"og:locale\" content=\"sl_SI\" \/>\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\/sl\/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\udd47Operacijski sistemi: Tri enostavna dela. Del 5: Na\u010drtovanje: Ve\u010dstopenjska povratnoinformacijska vrsta (prevod) | ProHoster","description":"Uvod v operacijske sisteme. Pozdravljen, Habr! Rad bi vam predstavil serijo prevodnih \u010dlankov zanimive literature - OSTEP.","canonical_url":"https:\/\/prohoster.info\/sl\/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":"sl_SI","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\/sl\/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\/sl\/wp-json\/wp\/v2\/posts\/32730","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/comments?post=32730"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/posts\/32730\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media\/24514"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/media?parent=32730"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/categories?post=32730"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/sl\/wp-json\/wp\/v2\/tags?post=32730"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}