{"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\/it\/blog\/administrirovanie\/operating-systems-three-easy-pieces-part-5-planirovanie-multi-level-feedback-queue-perevod","title":{"rendered":"Sistemi Operativi: Tre Facili Pezzi. Parte 5: Pianificazione: Coda di Feedback Multi-Livello (traduzione)","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<h1>Introduzione ai sistemi operativi<\/h1>\n<p>Ciao, Habr! Vorrei presentarvi una serie di articoli tradotti su una libreria che trovo interessante: OSTEP. In questo materiale si analizza in profondit\u00e0 il funzionamento dei sistemi operativi simili a Unix, in particolare la gestione dei processi, vari pianificatori, la memoria e altri componenti simili che costituiscono un moderno sistema operativo. Potete visualizzare l'originale di tutti i materiali qui <noindex><a rel=\"nofollow\" href=\"http:\/\/pages.cs.wisc.edu\/~remzi\/OSTEP\/\">qui<\/a><\/noindex>. Si prega di notare che la traduzione non \u00e8 stata eseguita da un professionista (\u00e8 abbastanza libera), ma spero di aver mantenuto il significato generale.<\/p>\n<p>Le esercitazioni su questo argomento possono essere trovate qui:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"http:\/\/pages.cs.wisc.edu\/~remzi\/OSTEP\/Homework\/homework.html\">originale<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/remzi-arpacidusseau\/ostep-code\">originale<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/github.com\/bykvaadm\/OS\/tree\/master\/ostep\">la mia personale adattamento<\/a><\/noindex><\/li>\n<\/ul>\n<p>Altre parti:<\/p>\n<ul>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/446340\/\">Parte 1: Introduzione<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/446866\/\">Parte 2: Astrazione: processo<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/447182\/\">Parte 3: Introduzione all'API dei processi<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/449026\/\">Parte 4: Introduzione al pianificatore<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/habr.com\/en\/post\/450116\/\">Parte 5: Pianificatore MLFQ<\/a><\/noindex><\/li>\n<\/ul>\n<p>E potete anche dare un'occhiata al mio canale su <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>Pianificazione: Coda di Feedback Multi-Livello<\/h2>\n<p>In questa lezione discuteremo delle problematiche nello sviluppo di uno degli approcci pi\u00f9 noti per<br \/>\nla pianificazione, noto come <b>Coda di Feedback Multi-Livello<\/b> (MLFQ). Il pianificatore MLFQ \u00e8 stato descritto per la prima volta nel 1962 da Fernando J. Corbat\u00f3 nel sistema chiamato<br \/>\nCompatible Time-Sharing System (CTSS). Questi lavori (inclusi i successivi contributi su<br \/>\nMultics) sono stati successivamente candidati per il premio Turing. Il pianificatore \u00e8 stato<br \/>\npoi perfezionato e ha assunto una forma che si pu\u00f2 vedere gi\u00e0 in<br \/>\nalcuni sistemi moderni.<\/p>\n<p>L'algoritmo MLFQ cerca di risolvere 2 problemi fondamentali che si sovrappongono.<br \/>\n<b>In primo luogo<\/b>, cerca di ottimizzare il tempo di turnaround, che come abbiamo esaminato nella lezione precedente, \u00e8 ottimizzato avviando in cima alla coda le<br \/>\nattivit\u00e0 pi\u00f9 brevi. Tuttavia, il sistema operativo non sa quanto tempo impiegher\u00e0 un processo, e questa<br \/>\n\u00e8 una conoscenza necessaria per il funzionamento degli algoritmi SJF, STCF. <b>In secondo luogo<\/b>, MLFQ cerca di<br \/>\nrendere il sistema reattivo per gli utenti (ad esempio per coloro che stanno seduti e<br \/>\nfissano lo schermo in attesa del completamento dell'attivit\u00e0) e in tal modo minimizzare il tempo<br \/>\nrisposta. Sfortunatamente, algoritmi come RR riducono il tempo di risposta, ma hanno un impatto molto negativo sulla metrica del tempo di turnaround. Da qui il nostro problema: Come progettare<br \/>\nun pianificatore che soddisfi le nostre esigenze e allo stesso tempo non sappia nulla della<br \/>\nnatura del processo, in generale? Come pu\u00f2 un pianificatore studiare le caratteristiche delle attivit\u00e0 che<br \/>\nlancia e quindi prendere decisioni migliori sulla pianificazione?<br \/>\nIl nocciolo della questione: Come pianificare l'assegnazione dei compiti senza una conoscenza perfetta?<\/p>\n<p><u>Come sviluppare un pianificatore che minimizzi simultaneamente il tempo di risposta<br \/>\nper compiti interattivi e riduca al contempo il tempo di turnaround senza una conoscenza predefinita<br \/>\ndel tempo di esecuzione del compito?<br \/>\nNota: impariamo dagli eventi passati.<\/u><\/p>\n<p>La coda MLFQ \u00e8 un ottimo esempio di un sistema che impara dai<\/p>\n<p>fatti trascorsi per prevedere il futuro. Approcci simili si trovano spesso nei sistemi operativi<br \/>\n(e in molti altri settori dell'informatica, comprese le ramificazioni<br \/>\ndi previsione nell'hardware e gli algoritmi di caching). Tali metodi<br \/>\nfunzionano quando le attivit\u00e0 hanno fasi comportamentali e sono quindi prevedibili.<br \/>\nsi attivano quando i compiti hanno fasi comportamentali rendendoli cos\u00ec prevedibili.<br \/>\nTuttavia, con questa tecnica \u00e8 importante essere cauti, poich\u00e9 le previsioni possono facilmente<br \/>\nrisultare errate e portare il sistema a prendere decisioni peggiori di quelle<br \/>\nche sarebbero state senza alcuna conoscenza.<\/p>\n<h3>MLFQ: Regole di base<\/h3>\n<p>Esaminiamo le regole di base dell'algoritmo MLFQ. Sebbene esistano diverse implementazioni di questo algoritmo,<br \/>\ngli approcci fondamentali sono simili.<br \/>\nNell'implementazione che considereremo, in MLFQ ci saranno pi\u00f9<br \/>\ncode separate, ognuna delle quali avr\u00e0 una priorit\u00e0 diversa. In qualsiasi momento,<br \/>\nil task pronto per l'esecuzione si trova in una delle code. MLFQ utilizza le priorit\u00e0<br \/>\nper determinare quale task eseguire, ovvero il task con priorit\u00e0 pi\u00f9 alta<br \/>\n(task dalla coda con priorit\u00e0 pi\u00f9 alta) verr\u00e0 eseguito per primo.<br \/>\nSenza dubbio, in una coda specifica possono esserci pi\u00f9 di un task, in questo<br \/>\nmodo avranno la stessa priorit\u00e0. In tal caso, verr\u00e0 utilizzato il meccanismo<br \/>\nRR per pianificare l'esecuzione tra questi task.<br \/>\nPertanto, arriviamo a due regole fondamentali per MLFQ:<br \/>\nRegola 1: Se priorit\u00e0(A) &gt; Priorit\u00e0(B), verr\u00e0 eseguito il task A (B non sar\u00e0 eseguito)<\/p>\n<ul>\n<li> Regola1: Se priorit\u00e0(A) &gt; Priorit\u00e0(B), verr\u00e0 avviato il compito A (B non verr\u00e0 avviato)<\/li>\n<li> Regola 2: Se priorit\u00e0(A) = priorit\u00e0(B), A e B vengono avviati utilizzando RR<\/li>\n<\/ul>\n<p>Sulla base di quanto sopra, gli elementi chiave per la pianificazione MLFQ<br \/>\nsono le priorit\u00e0. Invece di assegnare una priorit\u00e0 fissa a ciascun<br \/>\ncompito, MLFQ modifica la sua priorit\u00e0 in base al comportamento osservato.<br \/>\nAd esempio, se un compito continua a interrompere il lavoro della CPU in attesa di input da tastiera,<br \/>\nMLFQ manterr\u00e0 la priorit\u00e0 del processo alta, poich\u00e9 \u00e8 questo che<br \/>\ndeve fare un processo interattivo. D'altra parte, se un compito utilizza costantemente e<br \/>\nintensamente la CPU per un lungo periodo, MLFQ abbasser\u00e0 la sua<br \/>\npriorit\u00e0. In questo modo, MLFQ imparer\u00e0 il comportamento dei processi mentre vengono eseguiti<br \/>\ne utilizzer\u00e0 questi comportamenti.<br \/>\nDisegniamo un esempio di come potrebbero apparire le code in un certo momento<br \/>\ne quindi otterremo qualcosa del genere:<br \/>\n<img decoding=\"async\" alt=\"Sistemi Operativi: Tre Facili Pezzi. Parte 5: Pianificazione: Coda di Feedback Multi-Livello (traduzione)\" src=\"\/wp-content\/uploads\/2019\/04\/3598e9ca43a56049625bdcf3074de472.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>In questo schema, 2 processi A e B si trovano in coda con la massima priorit\u00e0. Il processo<br \/>\nC \u00e8 a met\u00e0 strada, mentre il processo D si trova alla fine della coda. Secondo le descrizioni fornite<br \/>\ndell'algoritmo MLFQ, il pianificatore eseguir\u00e0 solo i compiti con la massima priorit\u00e0.<br \/>\nla priorit\u00e0 secondo RR, mentre i task C e D saranno trascurati.<br \/>\nNaturalmente, uno snapshot statico non fornisce un quadro completo di come funziona MLFQ.<br \/>\n\u00c8 importante comprendere come cambia la situazione nel tempo.<\/p>\n<h4>Tentativo 1: Come modificare la priorit\u00e0<\/h4>\n<p>In questo momento \u00e8 necessario decidere come MLFQ cambier\u00e0 il livello di priorit\u00e0<br \/>\ndei task (e quindi la posizione del task nella coda) durante il loro ciclo di vita. Per<br \/>\nquesto \u00e8 necessario tenere a mente il flusso di lavoro: un certo numero di<br \/>\ntask interattivi con brevi tempi di esecuzione (e quindi frequenti rilasci di<br \/>\nCPU) e alcuni task lunghi, che utilizzano la CPU per tutto il loro tempo di lavoro, dando<br \/>\nuna scarsa importanza al tempo di risposta per tali task. E cos\u00ec si pu\u00f2 fare il primo tentativo<br \/>\ndi implementare l'algoritmo MLFQ con le seguenti regole:<\/p>\n<ul>\n<li> Rule3: Quando un task entra nel sistema, viene collocato nella coda con la priorit\u00e0 pi\u00f9 alta.<\/li>\n<li>priorit\u00e0.<\/li>\n<li>Rule4a: Se un task utilizza completamente il tempo assegnato, allora la sua<\/li>\n<li>priorit\u00e0 viene ridotta.<\/li>\n<li>Rule4b: Se il task rilascia la CPU prima della scadenza del suo tempo assegnato, allora rimane<\/li>\n<li>con la stessa priorit\u00e0.<\/li>\n<\/ul>\n<p><b>Esempio 1: Un singolo task a lungo termine<\/b><\/p>\n<p>Come si pu\u00f2 vedere in questo esempio, il compito viene assegnato con la massima priorit\u00e0<br \/>\n. Dopo una finestra temporale di 10 ms, il processo viene retrocesso in priorit\u00e0<br \/>\ndal pianificatore. Dopo la successiva finestra temporale, il compito viene infine retrocesso a<br \/>\nuna priorit\u00e0 inferiore nel sistema, dove rimane.<br \/>\n<img decoding=\"async\" alt=\"Sistemi Operativi: Tre Facili Pezzi. Parte 5: Pianificazione: Coda di Feedback Multi-Livello (traduzione)\" src=\"\/wp-content\/uploads\/2019\/04\/9b4ee6de03aa92d7957d50b4ffa73949.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p><b>Esempio 2: Un compito breve \u00e8 stato presentato<\/b><\/p>\n<p>Ora vediamo un esempio di come MLFQ cercher\u00e0 di avvicinarsi a SJF. In questo<br \/>\nesempio ci sono due compiti: A, che \u00e8 un compito a lunga durata che utilizza costantemente la CPU, e B, che \u00e8 un compito interattivo breve. Supponiamo<br \/>\nche A abbia gi\u00e0 lavorato per un certo periodo quando \u00e8 arrivato il compito B.<br \/>\nNel grafico sono visibili i risultati dello scenario. Il compito A, come qualsiasi compito<br \/>\n<img decoding=\"async\" alt=\"Sistemi Operativi: Tre Facili Pezzi. Parte 5: Pianificazione: Coda di Feedback Multi-Livello (traduzione)\" src=\"\/wp-content\/uploads\/2019\/04\/19c299b0519585fd1076a341a71f048b.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>che utilizza la CPU, si trova in fondo. Il compito B arriver\u00e0 a T=100 e sar\u00e0<br \/>\nposta nella coda con la priorit\u00e0 pi\u00f9 alta. Poich\u00e9 il suo tempo di esecuzione \u00e8 breve,<br \/>\nterminer\u00e0 prima di raggiungere l'ultima coda.<br \/>\nDa questo esempio si pu\u00f2 comprendere l'obiettivo principale dell'algoritmo: poich\u00e9 l'algoritmo non<\/p>\n<p>sa se un compito \u00e8 lungo o breve, assume innanzitutto che il compito<br \/>\nsa se un compito \u00e8 lungo o corto, quindi in primo luogo si presume che il compito<br \/>\nbreve e le d\u00e0 la massima priorit\u00e0. Se si tratta veramente di un compito breve,<br \/>\nsi completer\u00e0 rapidamente; altrimenti, se \u00e8 un compito lungo, proceder\u00e0 lentamente<br \/>\nnella priorit\u00e0 verso il basso e dimostrer\u00e0 presto di essere effettivamente un compito lungo che non<br \/>\nrichiede una risposta.<\/p>\n<p><b>Esempio 3: E per quanto riguarda l'input-output?<\/b><\/p>\n<p>Ora diamo un'occhiata a un esempio di input-output. Come affermato nella regola 4b,<br \/>\nse un processo libera la CPU senza utilizzare completamente il suo tempo di CPU,<br \/>\nallora rimane al suo livello di priorit\u00e0 attuale. Le intenzioni di questa regola sono abbastanza semplici:<br \/>\nse un compito interattivo esegue molte operazioni di input-output, ad esempio, in attesa<br \/>\ndi input da parte dell'utente, come tasti o mouse, tale compito liberer\u00e0 la CPU<br \/>\nprima della finestra prevista. Non vorremmo abbassare la priorit\u00e0 di tale compito,<br \/>\ne quindi rimarr\u00e0 al suo livello attuale.<br \/>\n<img decoding=\"async\" alt=\"Sistemi Operativi: Tre Facili Pezzi. Parte 5: Pianificazione: Coda di Feedback Multi-Livello (traduzione)\" src=\"\/wp-content\/uploads\/2019\/04\/480d33a670fb62a639e5938dd59e30a1.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>Questo esempio mostra come il algoritmo funzioner\u00e0 con tali processi: il compito interattivo B, che necessita di CPU solo per 1 ms prima di eseguire<br \/>\nil processo di input-output e il compito lungo A, che utilizza tutta la sua CPU.<br \/>\nMLFQ gestisce i processi con la massima priorit\u00e0, poich\u00e9 continua a liberare CPU nel frattempo.<br \/>\nSe B \u00e8 un compito interattivo, l'algoritmo in questo caso ha raggiunto<br \/>\nil suo obiettivo di avviare i compiti interattivi rapidamente.<\/p>\n<p><b>Problemi con l'algoritmo MLFQ attuale<\/b><\/p>\n<p>Negli esempi precedenti abbiamo costruito una variante base di MLFQ. Sembra che<br \/>\nstia svolgendo il suo lavoro bene e in modo equo, distribuendo il tempo di CPU equamente tra<br \/>\ncompiti lunghi e consentendo ai compiti brevi o quelli ad alta intensit\u00e0 di I\/O di completarsi rapidamente. Sfortunatamente, questo approccio presenta diversi<br \/>\nser\u00ee problemi.<br \/>\n, problema di starvation: se nel sistema ci sono molti compiti interattivi,<br \/>\n<b>In primo luogo<\/b>questi consumeranno tutto il tempo di CPU e di conseguenza nessun compito lungo<br \/>\navr\u00e0 l'opportunit\u00e0 di essere eseguito (starver\u00e0).<br \/>\n, utenti astuti potrebbero scrivere i loro programmi in modo tale da<\/p>\n<p><b>In secondo luogo<\/b>ingannare il piano di scheduling. L'inganno consiste nel fare qualcosa che costringa<br \/>\nil piano di scheduling a dare al processo pi\u00f9 tempo di CPU. L'algoritmo che<br \/>\nlo scheduler assegna pi\u00f9 tempo di CPU al processo. L'algoritmo che<br \/>\ncome descritto sopra, \u00e8 vulnerabile a questi attacchi: prima che la finestra di tempo sia praticamente<br \/>\nscaduta, \u00e8 necessario eseguire un'operazione di input\/output (su un file casuale, non importa quale)<br \/>\ne in questo modo liberare la CPU. Questo comportamento consentir\u00e0 di rimanere nella stessa<br \/>\ncoda e ottenere di nuovo una percentuale maggiore di tempo di CPU. Se fatto<br \/>\ncorrettamente (ad esempio, eseguendosi il 99% del tempo della finestra prima di liberare la CPU),<br \/>\nquesto compito pu\u00f2 semplicemente monopolizzare il processore.<\/p>\n<p>Infine, un programma pu\u00f2 modificare il proprio comportamento nel tempo. I compiti<br \/>\nche usavano la CPU possono diventare interattivi. Nel nostro esempio, tali<br \/>\ncompiti non riceveranno il giusto trattamento dal pianificatore, come riceverebbero altri<br \/>\n(iniziali) compiti interattivi.<\/p>\n<p><u>Domanda al pubblico: quali attacchi al pianificatore potrebbero essere effettuati nel mondo moderno?<br \/>\n<\/u><\/p>\n<h4>Tentativo 2: Aumento della priorit\u00e0<\/h4>\n<p>Proviamo a cambiare le regole e vediamo se riusciamo ad evitare i problemi di<br \/>\nstarvation. Cosa possiamo fare per garantire che i compiti legati alla<br \/>\nCPU ricevano il loro tempo (anche se non per molto).<br \/>\nCome soluzione semplice al problema, si pu\u00f2 proporre di aumentare periodicamente<br \/>\nla priorit\u00e0 di tutte queste attivit\u00e0 nel sistema. Esistono numerosi modi<br \/>\nper raggiungere questo obiettivo; proviamo a realizzare come esempio qualcosa di semplice: tradurre<br \/>\nsubito tutte le attivit\u00e0 alla massima priorit\u00e0, da qui la nuova regola:<\/p>\n<ul>\n<li><b>Rule5<\/b>: Dopo un certo periodo S, trasferire tutte le attivit\u00e0 nel sistema alla massima coda.<\/li>\n<\/ul>\n<p>La nostra nuova regola risolve immediatamente due problemi. In primo luogo, i processi<br \/>\nnon soffrono mai di starvation: le attivit\u00e0 nella coda prioritaria superiore condivideranno<br \/>\nil tempo della CPU secondo l'algoritmo RR e in questo modo tutti i processi riceveranno<br \/>\ntempo della CPU. In secondo luogo, se un processo, che in precedenza utilizzava<br \/>\nsolo la CPU, diventa interattivo, rimarr\u00e0 nella coda con priorit\u00e0 superiore dopo aver ricevuto<br \/>\nuna volta l'upgrade della priorit\u00e0 alla massima.<br \/>\nConsideriamo un esempio. In questo scenario consideriamo un processo che utilizza<br \/>\n<img decoding=\"async\" alt=\"Sistemi Operativi: Tre Facili Pezzi. Parte 5: Pianificazione: Coda di Feedback Multi-Livello (traduzione)\" src=\"\/wp-content\/uploads\/2019\/04\/3b8d879ab4479622684b126ec5af6af3.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>CPU e due processi interattivi, brevi. A sinistra, l'immagine mostra il comportamento senza elevazione di priorit\u00e0, e cos\u00ec un compito lungo inizia a soffrire di fame dopo l'arrivo nel sistema di due compiti interattivi. A destra, ogni 50 ms viene eseguita un'elevazione di priorit\u00e0, garantendo cos\u00ec che tutti i processi ricevano tempo di CPU e vengano eseguiti periodicamente. I 50 ms in questo caso sono stati scelti come esempio; in realt\u00e0, questo numero \u00e8 leggermente pi\u00f9 alto.<br \/>\n\u00c8 evidente che l'aggiunta di un tempo di elevazione periodica S porta a<br \/>\nuna questione inevitabile: quale valore dovrebbe essere impostato? Uno degli ingegneri di sistema pi\u00f9 rispettati, John Ousterhout, definiva simili grandezze nei sistemi come voodoo<br \/>\ncostante, poich\u00e9 in un certo senso richiedevano una sorta di magia nera per essere impostate correttamente.<br \/>\nE, sfortunatamente, S ha quell'aria. Se si imposta un valore troppo<br \/>\nalto, i compiti lunghi inizieranno a soffrire di fame. E se si imposta un valore troppo basso,<br \/>\ni compiti interattivi non riceveranno il giusto tempo di CPU.<br \/>\nTentativo 3: Migliore gestione<\/p>\n<h4>Tentativo 3: Miglior conteggio<\/h4>\n<p>Adesso abbiamo un altro problema da risolvere: come evitare<br \/>\nche il nostro pianificatore venga ingannato? I colpevoli di questa possibilit\u00e0 sono<br \/>\nle regole 4a e 4b, che permettono a un compito di mantenere la priorit\u00e0, liberando il processore<br \/>\nfino alla scadenza del tempo assegnato. Come possiamo affrontare questo?<br \/>\nUna possibile soluzione \u00e8 una migliore contabilizzazione del tempo CPU a ciascun<br \/>\nlivello MLFQ. Invece di dimenticare il tempo che un programma ha utilizzato<br \/>\nil processore durante il proprio intervallo, si dovrebbe tenere conto e conservarlo. Dopo che<br \/>\nil processo ha consumato il suo tempo assegnato, il suo livello di priorit\u00e0 deve essere abbassato<br \/>\nal livello successivo. Ora non importa come il processo utilizzer\u00e0 il suo tempo: sia<br \/>\ncome un calcolo continuo sul processore o come molteplici chiamate. In questo modo,<br \/>\ndobbiamo riscrivere la regola 4 nella forma seguente:<\/p>\n<ul>\n<li><b>Rule4<\/b>: Dopo che un compito ha consumato il tempo a disposizione nella coda attuale (indipendentemente da quante volte ha liberato la CPU), la priorit\u00e0 di quel compito viene abbassata (si muove verso il basso nella coda).<\/li>\n<\/ul>\n<p>Vediamo un esempio:<br \/>\n<img decoding=\"async\" alt=\"Sistemi Operativi: Tre Facili Pezzi. Parte 5: Pianificazione: Coda di Feedback Multi-Livello (traduzione)\" src=\"\/wp-content\/uploads\/2019\/04\/18c53e62b9b342d14a23995bd422ef5e.png\" style=\"display:block;margin: 0 auto;\">\u00bb<\/p>\n<p>La figura mostra cosa succede se si cerca di ingannare lo scheduler, come<br \/>\nse avessimo usato le precedenti regole 4a, 4b si otterrebbe il risultato a sinistra. Con la nuova<br \/>\nregola \u2014 il risultato \u00e8 a destra. Prima della protezione, qualsiasi processo poteva causare I\/O fino al termine e<br \/>\npertanto dominare la CPU, dopo l'attivazione della protezione, indipendentemente dal comportamento<br \/>\ndell'I\/O, verr\u00e0 comunque messo in coda in basso e quindi non potr\u00e0 appropriatamente<br \/>\nsottrarre risorse alla CPU.<\/p>\n<h4>Miglioriamo MLFQ e altri problemi<\/h4>\n<p>Con i miglioramenti sopra menzionati sorgono nuovi problemi: una delle principali<br \/>\nquestioni \u00e8 come parametrare uno scheduler simile? Cio\u00e8, quante dovrebbero essere<br \/>\nle code? Qual \u00e8 la dimensione della finestra di lavoro del programma all'interno della coda? Quanto<br \/>\nspesso dovrebbe essere aumentato il prioritario del programma per evitare l'starvation e<br \/>\nconsiderare il cambiamento del comportamento del programma? Non c'\u00e8 una risposta semplice a queste domande e solo esperimenti con carichi di lavoro e la successiva configurazione<br \/>\ndello scheduler possono portare a un certo equilibrio soddisfacente.<br \/>\nAd esempio, la maggior parte delle implementazioni di MLFQ consentono di assegnare diversi<\/p>\n<p>Ad esempio, la maggior parte delle implementazioni MLFQ consente di assegnare diversi<br \/>\nintervalli di tempo per varie code. Le code ad alta priorit\u00e0 di solito<br \/>\nricevono intervalli brevi. Queste code consistono in compiti interattivi,<br \/>\nla cui commutazione \u00e8 piuttosto sensibile e dovrebbe richiedere 10 millisecondi o meno.<br \/>\nIn contrapposizione, le code a bassa priorit\u00e0 consistono in compiti lunghi che utilizzano<br \/>\nla CPU. E in questo caso, lunghi intervalli di tempo sono molto adatti (100 ms).<br \/>\n<img decoding=\"async\" alt=\"Sistemi Operativi: Tre Facili Pezzi. Parte 5: Pianificazione: Coda di Feedback Multi-Livello (traduzione)\" src=\"\/wp-content\/uploads\/2019\/04\/4eb6c6669034adeb1615c29454fbb1dc.png\" style=\"display:block;margin: 0 auto;\"><\/p>\n<p>In questo esempio ci sono 2 compiti che hanno operato in una coda ad alta priorit\u00e0 per 20<br \/>\nms, suddivisi in finestre di 10 ms. 40 ms nella coda media (finestra di 20 ms) e nella coda a bassa priorit\u00e0<br \/>\nl'intervallo temporale \u00e8 diventato 40 ms, dove i compiti hanno completato il loro lavoro.<\/p>\n<p>L'implementazione di MLFQ nel sistema operativo Solaris \u00e8 una classe di pianificatori che dividono il tempo.<br \/>\nIl pianificatore fornisce un insieme di tabelle che definiscono esattamente come deve<br \/>\ncambiare la priorit\u00e0 di un processo nel corso della sua vita, quale dovrebbe essere la dimensione<br \/>\ndella finestra allocata e con quale frequenza devono essere aumentate le priorit\u00e0 dei compiti. L'amministratore<br \/>\ndi sistema pu\u00f2 interagire con questa tabella e forzare il pianificatore a comportarsi.<br \/>\ndiversamente. Per impostazione predefinita, in questa tabella ci sono 60 code con un aumento graduale<br \/>\ndella dimensione della finestra da 20 ms (alta priorit\u00e0) fino a diverse centinaia di ms (bassa priorit\u00e0), e<br \/>\nanche con un potenziamento di tutte le attivit\u00e0 ogni secondo.<\/p>\n<p>Altri pianificatori MLFQ non utilizzano una tabella o regole specifiche<br \/>\ncome descritto in questa lezione, ma calcolano le priorit\u00e0 utilizzando<br \/>\nformule matematiche. Ad esempio, il pianificatore in FreeBSD utilizza una formula per<br \/>\ncalcolare l'attuale priorit\u00e0 dell'attivit\u00e0, basandosi su quanto CPU<br \/>\nha utilizzato il processo. Inoltre, l'uso della CPU nel tempo degrada, e in questo<br \/>\nmodo l'innalzamento della priorit\u00e0 avviene in modo leggermente diverso da quanto descritto sopra. Questi sono<br \/>\ni detti algoritmi di decay. Dalla versione 7.1, in FreeBSD viene utilizzato il pianificatore ULE.<\/p>\n<p>Infine, molti pianificatori hanno altre caratteristiche. Ad esempio, alcuni<br \/>\npianificatori riservano i livelli superiori per il funzionamento del sistema operativo e in questo<br \/>\nmodo, nessun processo utente potr\u00e0 ottenere la massima priorit\u00e0 nel<br \/>\nsistema. Alcuni sistemi consentono di fornire suggerimenti per aiutare<br \/>\n\u00e8 possibile impostare correttamente le priorit\u00e0. Ad esempio, con il comando <b>nicely<\/b><br \/>\nsi pu\u00f2 aumentare o diminuire la priorit\u00e0 di un'attivit\u00e0, aumentando o<br \/>\ndiminuiendo le probabilit\u00e0 che il programma ottenga tempo di CPU.<\/p>\n<h3>MLFQ: Conclusioni<\/h3>\n<p>Abbiamo descritto un approccio alla pianificazione chiamato MLFQ. Il suo nome<br \/>\n\u00e8 legato al principio di funzionamento: ha pi\u00f9 code e utilizza il feedback<br \/>\nper determinare la priorit\u00e0 delle attivit\u00e0.<br \/>\nLa versione finale delle regole sar\u00e0 la seguente:<\/p>\n<ul>\n<li><b>Regola1<\/b>: Se priorit\u00e0(A) &gt; priorit\u00e0(B), verr\u00e0 avviata l'attivit\u00e0 A (B non verr\u00e0 avviata)<\/li>\n<li><b>Regola2<\/b>: Se priorit\u00e0(A) = priorit\u00e0(B), A e B vengono avviate utilizzando RR<\/li>\n<li><b>Regola3<\/b>: Quando un'attivit\u00e0 entra nel sistema, viene collocata nella coda con la priorit\u00e0 pi\u00f9 alta.<\/li>\n<li><b>Rule4<\/b>: Dopo che un compito ha consumato il tempo a disposizione nella coda attuale (indipendentemente da quante volte ha liberato la CPU), la priorit\u00e0 di quel compito viene abbassata (si muove verso il basso nella coda).<\/li>\n<li><b>Rule5<\/b>: Dopo un certo periodo S, trasferire tutte le attivit\u00e0 nel sistema alla massima coda.<\/li>\n<\/ul>\n<p>MLFQ \u00e8 interessante per il seguente motivo: invece di richiedere conoscenze sulla<br \/>\nnatura dell'attivit\u00e0 in anticipo, l'algoritmo studia il comportamento passato dell'attivit\u00e0 e imposta<br \/>\nle priorit\u00e0 di conseguenza. In questo modo cerca di sedere su due seggi contemporaneamente: ottenere prestazioni per le piccole attivit\u00e0 (SJF, STCF) e avviare equamente le lunghe<br \/>\nattivit\u00e0 che caricano la CPU. Perci\u00f2 molti sistemi, inclusi BSD e le loro derivate,<br \/>\nSolaris, Windows e Mac utilizzano una forma di algoritmo come pianificatore<br \/>\nMLFQ come base fondamentale.<\/p>\n<h4>Materiale aggiuntivo:<\/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>(informatica)<\/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>Fonte: <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.0.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. \u0412 \u044d\u0442\u043e\u043c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0435 \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0433\u043b\u0443\u0431\u043e\u043a\u043e \u0440\u0430\u0431\u043e\u0442\u0430 unix-\u043f\u043e\u0434\u043e\u0431\u043d\u044b\u0445 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c, \u0430 \u0438\u043c\u0435\u043d\u043d\u043e \u2014 \u0440\u0430\u0431\u043e\u0442\u0430 \u0441 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430\u043c\u0438, \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u043c\u0438 \u043f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0449\u0438\u043a\u0430\u043c\u0438, \u043f\u0430\u043c\u044f\u0442\u044c\u044e \u0438 \u043f\u0440\u043e\u0447\u0438\u0438\u043c\u0438 \u043f\u043e\u0434\u043e\u0431\u043d\u044b\u043c\u0438 \u043a\u043e\u043c\u043f\u043e\u043d\u0435\u043d\u0442\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u044e\u0442 \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u0443\u044e \u041e\u0421. \u041e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0432\u0441\u0435\u0445 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u0432 \u0432\u044b \u043c\u043e\u0436\u0435\u0442\u0435 \u043f\u043e\u0441\u043c\u043e\u0442\u0440\u0435\u0442\u044c \u0432\u043e\u0442 \u0442\u0443\u0442.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/it\/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.0.1\" \/>\n\t\t<meta property=\"og:locale\" content=\"it_IT\" \/>\n\t\t<meta property=\"og:site_name\" content=\"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47Operating Systems: Three Easy Pieces. Part 5: \u041f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435: Multi-Level Feedback Queue (\u043f\u0435\u0440\u0435\u0432\u043e\u0434) | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0425\u043e\u0447\u0443 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0432\u0430\u0448\u0435\u043c\u0443 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044e \u0441\u0435\u0440\u0438\u044e \u0441\u0442\u0430\u0442\u0435\u0439-\u043f\u0435\u0440\u0435\u0432\u043e\u0434\u043e\u0432 \u043e\u0434\u043d\u043e\u0439 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e\u0439 \u043d\u0430 \u043c\u043e\u0439 \u0432\u0437\u0433\u043b\u044f\u0434 \u043b\u0438\u0442\u0435\u0440\u0430\u0442\u0443\u0440\u044b \u2014 OSTEP. \u0412 \u044d\u0442\u043e\u043c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0435 \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0433\u043b\u0443\u0431\u043e\u043a\u043e \u0440\u0430\u0431\u043e\u0442\u0430 unix-\u043f\u043e\u0434\u043e\u0431\u043d\u044b\u0445 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c, \u0430 \u0438\u043c\u0435\u043d\u043d\u043e \u2014 \u0440\u0430\u0431\u043e\u0442\u0430 \u0441 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430\u043c\u0438, \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u043c\u0438 \u043f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0449\u0438\u043a\u0430\u043c\u0438, \u043f\u0430\u043c\u044f\u0442\u044c\u044e \u0438 \u043f\u0440\u043e\u0447\u0438\u0438\u043c\u0438 \u043f\u043e\u0434\u043e\u0431\u043d\u044b\u043c\u0438 \u043a\u043e\u043c\u043f\u043e\u043d\u0435\u043d\u0442\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u044e\u0442 \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u0443\u044e \u041e\u0421. \u041e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0432\u0441\u0435\u0445 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u0432 \u0432\u044b \u043c\u043e\u0436\u0435\u0442\u0435 \u043f\u043e\u0441\u043c\u043e\u0442\u0440\u0435\u0442\u044c \u0432\u043e\u0442 \u0442\u0443\u0442.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/it\/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\udd47Sistemi Operativi: Tre Facili Pezzi. Parte 5: Pianificazione: Coda di Feedback Multi-Livello (traduzione) | ProHoster","description":"Introduzione ai sistemi operativi Ciao, Habr! Vorrei presentarvi una serie di articoli-traduzioni di una letteratura che trovo interessante \u2014 OSTEP. In questo materiale viene esaminato in profondit\u00e0 il funzionamento dei sistemi operativi unix-like, in particolare \u2014 la gestione dei processi, dei vari pianificatori, della memoria e di altri componenti simili che compongono un sistema operativo moderno. Puoi visualizzare l'originale di tutti i materiali qui.","canonical_url":"https:\/\/prohoster.info\/it\/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":"it_IT","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Operating Systems: Three Easy Pieces. Part 5: \u041f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u0435: Multi-Level Feedback Queue (\u043f\u0435\u0440\u0435\u0432\u043e\u0434) | ProHoster","og:description":"\u0412\u0432\u0435\u0434\u0435\u043d\u0438\u0435 \u0432 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0435 \u0441\u0438\u0441\u0442\u0435\u043c\u044b \u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u0425\u043e\u0447\u0443 \u043f\u0440\u0435\u0434\u0441\u0442\u0430\u0432\u0438\u0442\u044c \u0432\u0430\u0448\u0435\u043c\u0443 \u0432\u043d\u0438\u043c\u0430\u043d\u0438\u044e \u0441\u0435\u0440\u0438\u044e \u0441\u0442\u0430\u0442\u0435\u0439-\u043f\u0435\u0440\u0435\u0432\u043e\u0434\u043e\u0432 \u043e\u0434\u043d\u043e\u0439 \u0438\u043d\u0442\u0435\u0440\u0435\u0441\u043d\u043e\u0439 \u043d\u0430 \u043c\u043e\u0439 \u0432\u0437\u0433\u043b\u044f\u0434 \u043b\u0438\u0442\u0435\u0440\u0430\u0442\u0443\u0440\u044b \u2014 OSTEP. \u0412 \u044d\u0442\u043e\u043c \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u0435 \u0440\u0430\u0441\u0441\u043c\u0430\u0442\u0440\u0438\u0432\u0430\u0435\u0442\u0441\u044f \u0434\u043e\u0441\u0442\u0430\u0442\u043e\u0447\u043d\u043e \u0433\u043b\u0443\u0431\u043e\u043a\u043e \u0440\u0430\u0431\u043e\u0442\u0430 unix-\u043f\u043e\u0434\u043e\u0431\u043d\u044b\u0445 \u043e\u043f\u0435\u0440\u0430\u0446\u0438\u043e\u043d\u043d\u044b\u0445 \u0441\u0438\u0441\u0442\u0435\u043c, \u0430 \u0438\u043c\u0435\u043d\u043d\u043e \u2014 \u0440\u0430\u0431\u043e\u0442\u0430 \u0441 \u043f\u0440\u043e\u0446\u0435\u0441\u0441\u0430\u043c\u0438, \u0440\u0430\u0437\u043b\u0438\u0447\u043d\u044b\u043c\u0438 \u043f\u043b\u0430\u043d\u0438\u0440\u043e\u0432\u0449\u0438\u043a\u0430\u043c\u0438, \u043f\u0430\u043c\u044f\u0442\u044c\u044e \u0438 \u043f\u0440\u043e\u0447\u0438\u0438\u043c\u0438 \u043f\u043e\u0434\u043e\u0431\u043d\u044b\u043c\u0438 \u043a\u043e\u043c\u043f\u043e\u043d\u0435\u043d\u0442\u0430\u043c\u0438, \u043a\u043e\u0442\u043e\u0440\u044b\u0435 \u0441\u043e\u0441\u0442\u0430\u0432\u043b\u044f\u044e\u0442 \u0441\u043e\u0432\u0440\u0435\u043c\u0435\u043d\u043d\u0443\u044e \u041e\u0421. \u041e\u0440\u0438\u0433\u0438\u043d\u0430\u043b \u0432\u0441\u0435\u0445 \u043c\u0430\u0442\u0435\u0440\u0438\u0430\u043b\u043e\u0432 \u0432\u044b \u043c\u043e\u0436\u0435\u0442\u0435 \u043f\u043e\u0441\u043c\u043e\u0442\u0440\u0435\u0442\u044c \u0432\u043e\u0442 \u0442\u0443\u0442.","og:url":"https:\/\/prohoster.info\/it\/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\/it\/wp-json\/wp\/v2\/posts\/32730","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=32730"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/32730\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/24514"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=32730"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=32730"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=32730"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}