Csökkentse alkalmazás válaszideje a linux, Rendszergazda
Dolgozik a számítógépen, folyamatosan szembesülnek különféle késések. Próbálja ki mindkét Campiglio mag, zenét hallgatni, a filmek letöltését a neten és a gépelés az OpenOffice.org. Biztos vagyok benne, hogy előbb-utóbb akkor szembe a tény, hogy író jelek jelennek után néhány másodperccel azután, hogy nyomjon meg egy gombot a billentyűzeten, és a játékos folyamatosan dadogás. Hogyan lehetséges, hogy csökkentsék a válaszidő alkalmazások Linux - az operációs rendszer a szétválás az idő. ahol minden folyamat egyenlők (majdnem)? Végül is, ez alakult összpontosítva optimalizálja a rendszer teljesítménye, mint egész, és biztosítani kell korlátozott válaszidő beszéd alkalmazások nem megy.
Az általunk használt eszközök kéznél
Mint ismeretes, a rendszer az élet származik a folyamatokat, amelyek kulcsszerepet játszanak bármilyen operációs rendszer. Gumialap nem, és annak ellenére, hogy a mértéktelen gigahertzes frekvencia egységnyi időre utasítások végrehajtására csak egy folyamat (az idő kvantum hívják a processzor kihasználtsága), és nagyon sok folyamatot a rendszer magukat. Így annak érdekében, hogy a késedelmek csökkentése, az eljárások száma minimalizálni kell. Ehhez meg kell, hogy ne csak a felesleges programokat és kikapcsolja az összes használt démonok, hanem újjáépíteni a kernel, így csak a valóban szükséges funkciókat.
Annak érdekében, hogy a forrásokat a kulturális és senki ugyanakkor ne fosszák, minden rendszer saját folyamatirányítási alrendszert. Ez azon az elven működik „hogy minden az ő képessége, hogy minden az ő munkáját”. A folyamat lehet működtetni két mód: core mód (kernel mód) és a felhasználói módban (user mode). ahol teljesíti az egyszerű utasításokat, amelyek nem igényelnek speciális „rendszer” az adatokat. De amikor az ilyen szolgáltatásokra van szükség, a folyamat belép a kernel módú, de az utasításokat továbbra is végezni nevében a folyamatot. Mindezt a célból, hogy megvédje alapvető működési tere a felhasználói folyamat. Más eljárások vagy készül indítani, várva az ütemező választja el, illetve az alvó üzemmódban (elalvás), várva jelenleg nem elérhető az erőforrás az idő. Az utóbbi egyszerű. Ha egy jelet a vezérelt eszköz, a folyamat kinyilvánítja TASK_RUNNING és sorban áll készen az indulásra. Ha ez a legmagasabb prioritású, a kernel vált annak végrehajtását.
De van egy másik zakovyrka. Amikor nyújtó folyamat rendszer erőforrásait bekövetkezik az úgynevezett kontextus kapcsolást (összefüggésben kapcsoló). megőrizve a kép a jelenlegi folyamat (ami mellesleg szintén szükséges ideig, így a várakozási idő is ideális esetben nulla lesz). Tehát keretében működik, ha az eljárás magmódban vezethet összeomlása az egész rendszer. Ezért a magas prioritású folyamat lesz türelmesen várni a pillanatot, az átmenet a feladat módban, akkor előfordulhat két esetben: a munkát, vagy szükséges erőforrás nem áll rendelkezésre. Azaz, hogy egy gyorsabb válaszidőt, szükséges, hogy minél kevesebb nukleáris alkalmazásokhoz. De egy ilyen döntés kötelezi a stabilitás és a „súlyát” kódot. Mikrokernel van, az úton, eladott sokkal jobb - van egy minimumát moduláris mást lógott, mint egy karácsonyfa, amely sokoldalú, és lehetővé teszi, hogy a tervezési rendszer meghatározott feladatok elvégzésére.
Ami a folyamatok tervezése, van kötve, hogy a prioritás. Scheduler egyszerűen kiválasztja a következő folyamatot a legmagasabb prioritást. Ebben az esetben az alacsonyabb prioritású folyamat fut egyszerre, talán még nem teljesen teljesítette a kvantum a végére. Minden folyamat kétféle prioritás: Relatív (p> szép, az alapértelmezett prioritás szinten 100), a telepített alkalmazás indításakor és a jelenlegi, amelyek alapján ütemezés bekövetkezik. Az érték a jelenlegi prioritás nem rögzített, hanem dinamikusan számított, és függ a szép. Az érték a felhasználó által megadott, lehet a -20 és +19, a kérelmet a magasabb prioritású érték megfelel a -20 és 10 (alapértelmezett) és a fent úgy tekintjük, hogy az alacsonyabb prioritású feladatokat. Például futtatni egy programot a normálisnál magasabb prioritású, ezt:
$ Sudo szép --20 mplayer
Egy alacsonyabb:
$ Sudo szép -20 munkát # 038;
Ha módosítani szeretné a relatív prioritását a folyamat, akkor használja a folyamat azonosítóját, ahelyett neve:
$ Sudo Renice --20 PID
Jelenlegi prioritása attól függ, hogy a szép idő és a rendszer erőforrásait. Ő újratervezi minden kullancs és a kilépés a kernel módban. A különböző rendszerek, ez történik a saját képleteket, a legegyszerűbb esetben egy prioritást osztva 2, és amikor eléri a nullát teljesen újratervezi (vissza). Ez a mechanizmus lehetővé teszi, hogy az időt és alacsony prioritású alkalmazások, de a végén a magas prioritású kapja a legtöbb belőle.
Mindezen finomságok használják a különböző kernelfolt végrehajtás lowlatency 2.4. Helyébe nemcsak a prioritás a jelenlegi átváltási algoritmusok, de az összes lehetséges konstans (pl szép határa emelkedett 256), továbbá egy időzítőt frekvencián akár 1000 HZ.
Annak érdekében, hogy jelezze azt az alkalmazást, különleges figyelmet igényel a processzor is használható, és beépített POSIX valós idejű leírások hívja SCHED_FIFO (egyfajta átmenet a „soft” real-time módban). Hasonló eredmény érhető el használatával SCHED_RR hívások, CAP_IPC_LOCK, CAP_SYS_NICE vagy helyettesítési értékek sys_sched_get_priority_max - egy függvény, amely visszaadja a maximális valós idejű prioritás. Ez a használata SCHED_FIFO okozza, hogy az XMMS lejátszó fut a gyökér, szinte dadogás még a túlzott terhelés a rendszerben.
A fő probléma a valós idejű az a képesség, hogy rögzítse források alacsony prioritású folyamat. különösen akkor, ha fut kernel módban. Végtére is, még a kontextusban kapcsolási töltött egy kis időt. Több száz a világ fejlesztői próbálta használni a több milliárd technológiák: a lehetőséget, megszakítás végrehajtása alatt magmódban (preemptív kernel, a kernel kiürül) egy ideiglenes öröklés (örökli) egy valós idejű prioritása alacsony prioritású alkalmazás. úgy, hogy gyorsan befejezni a kritikus szakasz a kódot, és így ellenőrzést.
Tárgy lapozható kernel a nyilvánosság érintett időszakban az uralom az 2.2 ág. Linus Torvalds azt mondta, hogy a valós idejű - egy rossz ötlet, és egyelőre preemptív valósult csak a segítségével javításokat. De a készítmény a lehetőséget, hogy ágaznak 2.6 kernel terheletlen (PREEMPT_RT) adunk a forráskódot. Preemptív-kernel végre, általában formájában egy második mag. Ha a folyamat fordul hozzá azzal a kéréssel, a fő rendszer ténylegesen blokkolja idején a végrehajtás. Végzett mindezt egy letölthető modul, amely felváltja / elfogja legkritikusabb függvény, ami késéseket. De nem minden ilyen egyszerű. Egy interjúban az egyik MontaVista mérnökök (vállalat-fejlesztő egyik valós idejű megoldások Linux alapú) azt mondta, hogy az 2.6-os rendszermag körülbelül 11.000 darab kódot egyszerűen lehetetlen csinálni preemptív.
Az interneten, ha egy jó kereső, megtalálja a kellő számú különböző foltok, amelyek lehetővé teszik, hogy végre valós idejű Linux, de mint általában, a legtöbb projekt már elavult, és változtatásokat javasol a kernel 2.4. Például, Kurt-Linux (www.ittc.ku.edu/kurt) és RT-Linux (www.rtlinux.org). Mindkét Linux hasonló technológiával, és a szubjektív különbségek a munka nem észrevehető, de az interneten dicsérte minden rendű és rangú jelentése RT-Linux. Keresse számítógépek ellenőrzése alatt lehetőség generátorok „tokamakká”, Peru, kórházak, a NASA műholdak szimulátor F111-C. By the way, ha az Ubuntu adja sudo apt-cache search valós idejű, akkor felfedezni a jelenlétét a csomagot a régi 3.1pre3-3 változata RT-Linux.
Foltok mag
A szabványos kernel elindítja a közüzemi rt-teszt. Csak fut, akkor kap egy értéket 0,125 ms, ha a terhelés növekszik, növeli a 15,402 ms. Megjegyzés: a beállítás kritériumok, ami egyenlő 100 ezredmásodperc. Ebben az esetben a vizsgálati eredmény - FAIL, vagyis a valós idejű még mindig messze. Tedd lowlatency-core - közös mag, csak egy időzítő 1000 Hz és a csökkentett válaszidő:
$ Sudo apt-get install linux-lowlatency
Újraindításra az rt-teszt újra.
$ Sudo rt-teszt minden
A kezdőérték most egyenlő a látencia 0,073 ms, és a legnagyobb - 2907 ms. Ez már jobb. Bár kritériumai még mindig nem, de Muzychko a Amarok'e nem szakad meg, ha egy tisztességes csomagtartó.
Az összes végrehajtásának valós idejű rendszerek, hogy csak az egyik jött ma kínált Molnár Ingó. Az a hír járta, hogy a tapaszok (www.kernel.org/pub/linux/kernel/projects/rt) az általa kibocsátott szerepelni fog kernel 2.6.22, de amíg ez megtörténik. Fedora telepítéséhez rt rajongók egyszerűen írja yum install kernel-rt, mások kis pokompilirovat. Töltse le és alkalmazza a tapaszt a kernel:
$ Wget -c www.kernel.org/pub/linux/kernel/projects/rt/older/patch-2.6.22.1-rt9
$ Tar xjvf linux-2.6.22.1.tar.bz2
$ Cd linux-2.6.22.1
$ Sudo patch -p1
Amikor konfigurálja talált számos további paramétereket. Közülük tickless rendszer (Dynamic kullancsok) (NO_HZ) - dinamikusan változtatni a kullancs; Nagy felbontású időzítő Support (HIGH_RES_TIMERS) - nagy felbontású időzítő. Szakaszban Preemption Mode minket érdeklő Complete Preemption (Real-Time) (PREEMPT_RT), bár egyelőre nem Forced Preemption (szerver) (PREEMPT_NONE), Önkéntes Kernel Preemption (Desktop) (PREEMPT_VOLUNTARY), preemptív Kernel (alacsony késleltetésű Desktop) (PREEMPT_DESKTOP ). Szakaszban «blokkréteg - Default I / O ütemező» megjelent teljesen igazságos ütemező sorban CFS.
Az újraindítás után a rendszer, ha beírja a dmesg, akkor láthatjuk, hogy a kernel volt előjegyző RT, az időzítés nem stabil ( «Clocksource TSC instabil») és ps aux jelenlétét mutatja a nagyszámú új folyamatokat. De mi jobban érdekli az eredmény az rt-tesztet. Így minden kedves trükkök vezettek, amit ma a maximális várakozási idő kevesebb, mint 0,07 ms. Voila, vizsgált át!