Introductio ad Systema Operating
Salve, Habr! Volumus autem operam tuam dare seriem articulorum-translationum unius litterarum, quae mea sententia interest - OSTEP. Haec materia penitus penitus examinat opus systematum unix-similes operandi, scilicet operari cum processibus, variis schedulis, memoria et aliis similibus elementis quae recentiorem OS constituunt. Potes videre originale omnium materiarum hic . Nota quaeso translationem (satis libere (satis) factum esse), sed communem significationem spero me retinuisse.
Laboratorium hac de re hic inveniri potest;
Aliae partes:
Potes etiam reprehendo meum in alveum suum =)
Consilium: Multi-Level videre queue
In hac lectione loquemur de quaestionibus enucleandis unus aditus celeberrimus
consilio, quod dicitur Multi-Level videre queue (MLFQ). MLFQ scheduler primo anno 1962 a Fernando J. Corbató in systemate vocato descriptus est
Compatible Time-Sharing System (CTSS). Haec opera (including post opus est
Multics) postea pro Turing lacus nominati sunt. Consilium erat
deinde emendavit et acquisivit speciem quae iam inueniri potest
quaedam moderna.
MLFQ algorithmus II fundamentales quaestiones imbricatis solvere conatur.
Primoconatur ad optimize tempus inverso, quod, sicut in superiori lectione tractatum est, per modum incipiendi ab ineunte maxime queue optimizatur.
brevibus operibus. Sed OS nescit quousque processus particularis currat, et hoc
scientia necessaria ad operationem algorithmorum SJF, STCF. Secundo, MLFQ conatur
systema dociles pro users (exempli gratia, pro sedentibus et
conspiciunt in screen expectantes opus perficere) et sic magna tempus
responsio. Infeliciter, algorithmi sicut RR tempus meliorem responsionem praebent, sed perquam
male ictum in turnaround temporis metrica. Hinc nostra quaestio: Quomodo designet?
a scheduler quod in occursum nobis requisitis nesciens aliquid de
ratione processus generatim? Quomodo cedularum notas cognoscere possit officiorum?
quo intorquet et sic melius consulit?
Essentia problematum: Quomodo institutio operum sine perfecta scientia?
Quomodo designare scheduler quod eodem tempore regit responsio temporis?
Nam interactive munia et simul Regium turnaround nesciens
cogni- tionis exactio tempus?
Nota: ex antecedentibus discimus
Queue MLFQ optimum exemplum systematis discit ex
praeterita futura praedicere. Similia aditus saepe
inveniuntur in OS (Et multi alii rami scientiarum computatrorum, e quibus rami sunt
praedictiones hardware et algorithms caching). Similia itinera
Urguet cum muneribus se gerendi gradus habent et sic praedictio est.
Sed de hac arte cavere debes quia praedictiones facillime sunt
ut eveniat falsa et ducunt systema ad peius iudicium quam
omnino careat scientia.
MLFQ: Basic Rules
Inspiciamus regulas fundamentales algorithm MLFQ. Et quamvis exsecutiones huius algorithmi
Plures sunt, aditus basic similes.
In exsecutione spectabimus, MLFQ plures habebimus
separa- tiones, quarum unaquaeque aliam prioritatem habebit. Quisquam,
negotium ad supplicium paratum est in una queue. MLFQ potioribus utitur;
uter utri negotium ad supplicium, i.e. negotium cum superiore
prioritas (opus a queue cum summa prioritate) primum deducetur
queue.
Sane plus quam unum opus in dato queue potest esse
sic habebunt eandem prioritatem. Hoc in casu, machinatio adhibebitur
RR RATIONARIUM curriculum inter haec munia.
Sic ad duas regulas fundamentales pro MLFQ devenimus:
- Rule1: Si prioritas (A) > prioritas (B), negotium A deducetur (B non)
- Rule2: Si prioritas (A) = prioritas (B), A & B incipiunt uti RR
Ex superioribus elementis elementorum ad consilium MLFQ fundatum est
potiores. Sed certum prius unicuique
negotium, MLFQ mutat suum prioritatem secundum mores observatos.
Exempli gratia, si negotium constanter in CPU laborem iacit dum claviaturae input expectatur,
MLFQ servabo processus prioritatem excelsum quod est quomodo
processus interactive laboret. Si e contra, negotium constanter et
utitur CPU graviter per longum tempus, MLFQ demittet
prioritas. MLFQ ergo moribus processuum studebit dum currunt
et mores utere.
Exemplum ducamus quid stantibus anteponere posset in aliquo puncto
et tunc aliquid simile hoc habes:
In hoc schemate, 2 processus A, B sunt in summa prioritate queue. Processus
C alicubi est in medio, et processus D in ipso fine queue. Secundum superius
Secundum descriptiones algorithmi MLFQ, schedula munera tantum cum summis facient
prioritas secundum RR, operaque C, D ex opere erunt.
Naturaliter snapshot static non dabit integram imaginem quomodo MLFQ operatur.
Praestat plane intelligere quomodo imago in tempore mutat.
Tempt I: quomodo mutare prioritatem
Hic debes iudicare quomodo MLFQ gradu prioritatem mutabit?
munera (sicque operis positio in queue) ut per suum vitae cursum progrediatur. For
hoc memorari necesse est in workflow : aliquantulum
interactive negotium cum brevi runtimes (et sic crebra emissio
CPU) et plura negotia diuturna, quae CPU utuntur omni operando tempore, dum
Responsio temporis non est magni momenti pro talibus officiis. Et hoc modo experiri potes
deducendi algorithmum MLFQ cum sequentibus regulis:
- Rule3: Cum negotium systematis intrat, in queue cum supremo ponitur
- prioritas.
- Rule4a: Si negotium totum tempus fenestrae illi attributae utitur, tum est
- prioritas reducitur.
- Rule4b: Si Negotium dimittit CPU ante tempus suum fenestram exspirat, tunc
- manet eadem prioritate.
Exemplum I: Una diu cursus negotium
Sicut patet in hoc exemplo, opus admissio cum supremo constituitur
prioritas. Post tempus fenestrarum 10 librarum, processus in prioritate est detentus
consiliumque. Proximo tempore post fenestram, negotium tandem deponitur
ima ratio prioritatis, ubi restat.
Exemplum II: brevi liberavit negotium
Nunc videamus exemplum quomodo MLFQ accedere SJF conabitur. In illo
exempli gratia duo opera: A, quod est opus diuturnum constanter
occupans CPU et B, quod opus breve interactive. Esto
A iam per aliquod temporis spatium laborasse B pervenit.
Hoc graphi eventus ostendit missionis. Molestiae, ut ullam,
CPU in ipso fundo usus erat. Negotium B perveniet ad tempus T=C et voluntatem
in summa prioritate queue. Cum operandi tempus breve est, tunc
complebit antequam ad ultimum queue.
Ex hoc exemplo, intelligendus est principalis finis algorithmus: quoniam algorithmus non est
scit num opus sit longum an breve, tunc primum id munus sumit
brevis et summa prioritas dat. Si hoc munus breve est, tunc
hoc celeriter perficietur, alioquin, si opus est, tardius movebitur
prioritas deprimatur et mox probabit ipsam esse munus longum quod non est
responsum requirit.
Exemplum III: Quid de me/o?
Nunc inspiciamus exemplum I/O. Sicut in regula 4b;
si processum emittit processus sine utendo omni processu temporis;
tunc manet in eodem gradu prioritatis. Intentio huius regulae est omnino simplex
- si officium interactive multum praestat operationibus I/O, exempli gratia, exspectans
e clavis usoris vel muris pressis, tale negotium processus liberabit
ante datam fenestram. Nolumus prioritatem huius operis demittere;
et sic remanebit in eodem gradu.
Hoc exemplum ostendit quomodo algorithmus talibus processibus laborabit - officium interactivum B, quod solum CPU pro 1ms ante executionem indiget.
I/O processus et cursus Iob A, qui toto suo tempore utitur in CPU.
MLFQ habet processum B ad summam prioritatem quia pergit
dimittere CPU. Si B negotium interactivum est, algorithmus effectum est
Propositum tuum est opera interactive celeriter currere.
Problemata cum algorithmo MLFQ currenti
In exemplis praecedentibus fundamentalem versionem MLFQ aedificavimus. Et videtur quod
bene et honeste suum officium facit, CPU tempore satis inter distribuens
longa munia et permittens brevia munia vel valde accessed tasks
opus in I / O cito. Infeliciter, hic aditus plures continet
gravibus quaestionibus.
Primoquaestio de fame: si ratio multa habet interactive
opera, omnia CPU tempore consumet et ita ne unum quidem diu
negotium exsecutioni mandari non poterit (they are staving).
Secundo, usores callidi programmata scribere potuerunt ut
stulte cedula. Deceptio mendacium est in faciendo aliquid ad vim
Schedularius processus plus temporis CPU dat. Algorithmus that
supra descriptus est satis vulnerabilis ad similes impetus: ante tempus fenestram prope est
finivit, debes operandi I/O operandi (quibusdam, utcumque fasciculis)
et sic liberat CPU. Tales mores te in eodem manere sinent
ipsa queue et iterum maiorem recipis partem temporis CPU possidebit. Si facis
hoc verum est (exempli gratia, exsequere XCIX% fenestrae tempus antequam dimittens CPU);
tale negotium processus simpliciter monopolire potest.
Progressio denique mores suos in tempore mutare potest. Illa negotia
quae usus CPU interactive fieri potest. In exemplo nostro, similiter
opera non recipiant curationem mereantur a scheduler sicut alii
(Initial) interactive munia.
Quaeritur auditoribus: quae impetus in schedula exerceri potuit in mundo huius temporis?
Conatus II: Augenda prioritas
Studeamus regulas mutare et vide si difficultates cum vita possumus
jejunium. Quid faciemus ut related?
CPU opera tempus suum habebunt (etiamsi non diu).
Simplex solutio quaestionis, periodice suggerere potes
omnium talium officiorum in systemate prioritatem erigimus. Sunt multi modi
Ad hoc assequendum, quoddam simplex exemplum efficere conemur: translate
omnia opera statim summa prioritate donantur, inde nova regula;
- rule5: Post aliquod tempus S, omnia opera in systemate summo queue movent.
Nostra nova regula duas problemata simul solvit. Primo, de processibus
spondet non esurire: munia quae in summa prioritate dividentur
CPU tempus secundum algorithmum RR et sic omnes processus recipiet
CPU tempus. Secundo, si aliquis processus, qui ante usus est
modo processus fit interactive, in queue cum supremo manebit
prioritas post unum tempus augetur prioritate summa.
Intueamur exemplum. In hoc missione, vide unum processum utendi
CPU et duo interactive, processus breves. In figura sinistra, figura mores sine prioritate promotionis ostendit, et sic opus diuturnum incipit esurire postquam duo opera interactiva in systemate perveniunt. In figura dextra, incrementum prioritatis singulis 50ms perficitur et sic omnes processus spondentur ad tempus CPU recipiendum et periodice deducentur. 50ms in hoc casu sumatur in exemplum, revera hic numerus paullo superior est.
Patet, addito incremento periodico temporis S ducit to .
quaestio logica: quid pretii statui debet? Unus honoratus
machinarum machinarum Ioannes Ousterhout vocavit tantas quantitates in systematibus sicut voo-doo
constantes, quia magicae nigrae aliquo modo ad rectam requiruntur
exhibens. Et proh dolor, S talem odorem habet. Si pone valorem quoque
magna - longa negotia incipient esurire. Et si demissior aestimas;
Interactive munera non recipiet tempus proprium CPU.
Conatus III, Potius Accounting
Nunc aliam quaestionem solvendam habemus: quomodo non
nostros deludi permittitis scheduler? Populus reprehendat hanc facultatem are
praecepta 4a, 4b, quae officium prioritatem retinere permittit, processus usque liberans
ante tempus expirat. Quomodo hoc agat?
Solutio in hoc casu melior ratiocinatio CPU temporis in singulis considerari potest
Herennius MLFQ. Instead of oblitus tempus progressio usus est
processus pro tempore sortitus sit habenda ratio et salvatio. Post
processus usus suum tempus sortitus est, debet demoveri ad proximum
prioritas, planities. Nunc non refert quomodo processus tempore suo utetur - quomodo
constanter computando in processus vel sicut numerus vocat. Sic,
regula 4 in hac forma revocetur;
- rule4Post negotium suum tempus in currente queue (quamvis CPU absolvit) usus est, prioritas illius operis deprimitur (queue deprimit).
Intueamur exemplum:
»
Figura ostendit quid acciderit si stulte schedulam conaris, sicut
si cum 4a, 4b in sinistris haberetur. Laetus novus
regula in iure fit. Ante tutelam, processus aliquis appellare potuit I/O ante complementum et
ita CPU dominantur, post tutelam, cuiuscumque mores
I/O, in queue adhuc movebitur et sic inhoneste non poterit
CPU facultates possidendam.
Improving MLFQ et alia problemata
Cum melioramentis venit super novas difficultates: unus principalis
Quaeritur: Quomodo parameter est talis schedula? Illae. Quantum debet esse
queues? Quid debet esse amplitudo programmatis fenestrae intra queue? Quam
Programma prioritas saepe augetur ad vitandam famem et
rationem mutationis in progressio morum? Non est simplex responsum ad has quaestiones
respondere et experimenta tantum cum onerat et configuratione subsequenti
consiliumque potest ducere ad aliqua satis iusta.
Exempli gratia, maxime MLFQ implementationes permittunt te diversum assignare
temporibus diversis Queues. Maxime stantibus anteponere
intervalla brevia praescribuntur. Queues hae interactive functiones constant;
commutatio inter quae satis sensitiva est et debet accipere 10 vel minus
ms. E contra, humilis-prioritas queues ex diuturna negotia, quae usu sunt, constant
CPU. Et in hoc casu longi temporis intervalla optime conveniunt (100ms).
In hoc exemplo operae 2 sunt quae in summo prioritate queue 20 . laboraverunt
ms, in 10ms fenestras divisa. 40ms in medio queue (20ms fenestra) et in low prius
Queue fenestra temporis facta est 40morum ubi munera opus suum compleverunt.
Solaris OS exsequendum MLFQ genus schedulae temporis participat.
Consilium tabularum statutum providebit quae prorsus definiant sicut oportet
prioritas processus in decursu vitae suae mutat, quae debet esse magnitudo
fenestra partita et quotiens opus est tibi potiorum negotium attollere. Administrator
systems potest mutuam hanc mensam ac faciam scheduler conversari
aliter. Defalta haec tabula 60 queues habet cum paulatim incremento
fenestrae magnitudinis ex 20ms (summa prioritate) ad plures centum ms (low prioritatis), et
etiam cum boost omnia opera semel per alterum.
Aliae MLFQ ordinatores non utuntur ad mensam vel aliquo specifico
regulae, quae in hac lectione describuntur, e contra, potiores computant utentes
formulae mathematicae. Exempli gratia, FreeBSD scheduler formula pro . utitur
computare current prioritas operis fundatur quousque processus sit
usus est CPU. Praeterea usus CPU tempore decrescit, et sic
Crescente igitur prioritate aliquantum aliter accidit quam supra dictum est. Haec sit vera
vocatur algorithms caries. Cum versio 7.1, FreeBSD ULE schedula usus est.
Denique multae cedulae aliae lineamenta habent. For example, some-
cedulas supremas reservant ad operationem systematis operantis et sic
Nullus igitur processus usoris summam prioritatem capere potest
ratio. Quaedam systemata permittunt ut consilium des auxilium
consiliumque de prioritatibus recte potest. Verbi gratia utens imperio bellum
augere vel diminuere potes prioritatem operis et sic augere vel
reducere in programmatis casus utendi CPU tempore.
MLFQ: Summarium
Ac- tionem dicta MLFQ descripsimus. Nomen sibi
inclusum in principio operationis - plures queues et opiniones habet
negotium prioritate determinare.
Postrema forma regularum talis erit:
- rule1: Si prioritas (A) > prioritas (B), negotium A deducetur (B non)
- rule2: Si prioritas (A) = prioritas (B), A & B incipiunt uti RR
- rule3: Cum negotium systematis intrat, in summa prioritate queue ponitur.
- rule4Post negotium suum tempus in currente queue (quamvis CPU absolvit) usus est, prioritas illius operis deprimitur (queue deprimit).
- rule5: Post aliquod tempus S, omnia opera in systemate summo queue movent.
MLFQ interest propter hanc causam - pro scientia de "
natura praevia muneris, algorithmus de praeteritorum operum moribus studet et ponit
potiores, proinde. Ita in duabus sellis simul sedere nititur - ut fructibus parvis operibus (SJF, STCF) sedere studeat et ad diuturnitatem honeste currendam;
CPU-loading jobs. Multae igitur systemata, etiam BSD et earum derivationes;
Solaris, Fenestra, Mac uti aliqua algorithmi forma sicut cedularum
MLFQ baseline ut.
Additional materiae:
- (Computing)
Source: www.habr.com