Real-time modifikace Linuxu - 1 (RTLinux a RTAI)

25. 1. 2006 | Vít Pelčák

Články - Real-time modifikace Linuxu - 1 (RTLinux a RTAI)  

Prozkoumání možností modifikací operačního systému GNU/Linux pro práci v reálném čase. Zaměřeno především na plánování úloh reálného času v běžném Linuxu. Analýza vlivů několika variant preemptivního jádra na časové odezvy procesů reálného času. Srovnání hard real-time linuxových modifikací (RTLinux, RTAI).

Obsah

První díl

1. ÚVOD
  1.1 Co je to Linux
  1.2 Probírané linuxové real-time modifikace
    1.2.1 RTLinux
    1.2.2 RTAI/fusion
    1.2.3 Realtime preempt patch
2. RTLINUX
  2.1 Úvod
  2.2 POSIX
    2.2.1 Základní pojmy
    2.2.2 Plánování
    2.2.3 Posixio
    2.2.4 Signály
  2.3 Shrnutí
3. RTAI
  3.1 Úvod
    3.1.1 Úvod do RTAI/fusion
  3.2 Časovače a přerušení
  3.3 Základní koncepty
  3.4 Software
  3.5 Podporované architektury

Druhý díl

4. REALTIME PREEMPT MODIFIKACE JÁDRA
  4.1 Souběžnost v jednoprocesorovém jádře
    4.1.1 Kritické úseky a jejich správa
  4.2 Souběžnost na SMP jádře a správa kritických úseků
    4.2.1 Ochrana před jinými vlákny
  4.3 Analýza prodlev preemptivního jádra
    4.3.1 Prodlevy přerušení
    4.3.2 Prodlevy závislé na úlohách
    4.3.3 Shrnutí
  4.4 Plně preemptivní real-time jádro
    4.4.1 Vylepšení real-time zpracování úloh
    4.4.2 Nezávislost kritických úseků
    4.4.3 Nahrazování Spinlocku
    4.4.4 Shrnutí
    4.4.5 Vlastnosti Real-Time jádra
    4.5.1 Dědičnost priorit
  4.6 Benchmarky
    4.6.1 Interbench
  4.7 Shrnutí
5. APLIKACE
  5.1 Embedded systémy a jiné aplikace pro řízení
  5.2 Multimediální aplikace - JACK
6. ZÁVĚR

Poznámka redakce: materiál pro tento seriál vychází ze semestrální práce. Ačkoliv byl upraven tak, aby vyhovoval formátu článků na abclinuxu.cz, byly v něm ponechány některé kapitoly, v nichž jsou vysvětlovány pojmy, které většina čtenářů pravděpodobně již zná.

1. ÚVOD

Cílem seriálu je prozkoumání možností modifikací operačního systému Linux pro práci v reálném čase, srovnání hard real-time variant Linuxu a porovnání vlivů variant preemptivního jádra na časovou odezvu procesů reálného času.

1.1 Co je to Linux

Operační systém GNU/Linux je svobodná implementace Unixu vyvíjená Linusem Torvaldsem a týmem programátorů a hackerů mající za cíl vytvořit operační systém podle norem POSIX a Single UNIX Specification.

Linux má všechny vlastnosti, které se od moderního plnohodnotného unixového operačního systému očekávají.

Je také šířen zdarma pod licencí GNU/GPL a jsou u něj k dispozici zdrojové kódy.

1.2 Probírané linuxové real-time modifikace

1.2.1 RTLinux

RTLinux je komerční linuxová real-time modifikace, která kromě úpravy jádra přináší také sadu vlastních nástrojů a modulů, které dodatečně rozšiřují možnosti jádra. Snaží se co nejvíc přiblížit POSIX 1003.1 Real-Time standard specifikaci.

1.2.2 RTAI/fusion

RTAI/fusion je v podstatě přídavný modul, který využívá služeb HAL (Hardware Abstraction Layer), což je abstraktní vrstva nad hardwarem. Snaží se o přesunutí běhu procesů z prostoru jádra do uživatelského prostoru, a taky dokáže tyto nelinuxové systémy emulovat. Tím lze zjednodušit přechod aplikací z jiných real-timových operačních systémů na systémy založené na Linuxu. RTAI/fusion je volně ke stažení na adrese http://www.rtai.org/.

1.2.3 Realtime preempt patch

Je to úprava zdrojových souborů Linuxu, kterou vyvíjí Ingo Molnar, snažící se o řešení vysokých prodlev linuxového jádra a mimo jiné do jádra přináší několik variant preemptivity. Tato se projevila jako natolik užitečná, že některé její části jsou přejímány i do samotného linuxového jádra. Tato úprava je volně ke stažení na internetové adrese http://people.redhat.com/mingo/realtime-preempt/.

2. RTLINUX

2.1 Úvod

RTLinux je hard real-time varianta Linuxu, která umožňuje ovládání robotů, data pořizujících systémů, zařízení citlivých na čas, výrobních dílen a dalších nástrojů.

1. verze RTLinuxu byla navržena pro provoz na levnějších a méně výkonných počítačích založených na x86. Poskytovala však pouze spartánské API a programovací prostředí.

2. verze RTLinuxu byla zcela přepsána. Podporuje symetrický multiprocessing, pracuje na větším rozsahu systémů a má spoustu rozšíření pro zjednodušení použití.

RTLinux nabízí možnost běhu speciálních real-time úloh a obslužných rutin přerušení (interrupt handlers) na stejném PC jako standardní Linux. Tyto úlohy a obslužné rutiny se vykonávají podle potřeby bez ohledu na to, co Linux právě dělá. V nejhorším případě je čas mezi okamžikem, kdy je procesorem detekováno přerušení, a okamžikem, kdy začne pracovat rutina obsluhující toto přerušení, minimálně 15 mikrosekund. Periodické úlohy v RTLinuxu na stejném hardware běží během 25 mikrosekund od naplánovaného okamžiku. Tyto časy jsou omezeny hardwarem, a jak se hardware vyvíjí, tak se zlepšuje i výkon RTLinuxu. Standardní Linux má skvělý průměrný výkon a může dokonce poskytovat řádově milisekundovou přesnost plánování úloh použitím POSIXových soft real-time schopností. Standardní Linux není navržen tak, aby poskytoval přesnost pod milisekundu a spolehlivé časovací záruky.

RTLinux druhé verze je strukturován jako soubor volitelných komponentů doplňujících jádro.

Jádro povoluje instalaci obslužných rutin přerušení s velmi nízkou prodlevou (Low Latency). Tento hlavní komponent byl rozšířen o podporu SMP (Symetric MultiProcessing) a zároveň je zjednodušen odebráním některých vlastností, které mohou být poskytovány jiným způsobem.

Hlavní funkčnost RTLinuxu spočívá v kolekci modulů poskytujících volitelné služby a úrovně abstrakce.

Tyto moduly zahrnují:

1. rtl sched - plánovač priorit, který podporuje "jako POSIXové" rozhraní a původní v1 RTLinux API.
2. rtl time - který řídí hodinový signál procesoru a exportuje abstraktní rozhraní pro připojení obslužných rutin na hodinový signál.
3. rtl posixio - podporuje POSIX styl read/write/open rozhraní pro ovladače zařízení.
4. rtl fifo - propojuje RT úlohy a obslužné rutiny přerušení k linuxovým procesům přes vrstvu zařízení, takže linuxové procesy mohou číst a zapisovat do RT komponent.
5. semaphore - dává RT úlohám blokovací semafory (synchronizační objekty, které slouží k synchronizaci přístupu ke sdíleným prostředkům). Podpora POSIXových mutexů bude taky k dispozici.
6. mbuff - poskytuje sdílenou paměť mezi RT komponenty a linuxovými procesy (Yodaiken, V., Barabanov, M.).

Klíčovým cílem návrhu RTLinuxu je transparentní, modulární a rozšiřitelný systém. Transparentnost znamená, že zde nejsou žádné neotevíratelné černé skříňky a cena každé operace by měla být stanovitelná. Modularita znamená, že je možné vynechat nepotřebnou funkci a ušetřit tak výkon. Základní RTLinux systém podporuje pouze vysokorychlostní obsluhu přerušení. Rozšiřitelnost znamená, že programátoři by měli být schopni přidat moduly a upravit si systém podle vlastních požadavků.

2.2 POSIX

2.2.1 Základní pojmy

POSIX 1003.1 Real-Time standard je pro hard real-time stejně nedosažitelný jako nutný. Nedosažitelný je kvůli přímé implementaci například POSIXového souborového systému. Má požadavky, které real-time systém nemůže poskytnout. Nutný je proto, že nabízí jediné široce používané rozhraní pro real-time, zařizuje propojení a přesun software mezi real-time a ne-real-time POSIXovými systémy.

RTLinux v2 se přibližuje POSIX real-time specifikacím následováním modelu pro POSIXový jednoprocesorový/minimální real-time systém s některými rozšířeními pro SMP. POSIXový návrhový standard definuje "Minimální real-time systémový profil" (PSE51), který je zamýšlený pro hard real-time systémy jako RTLinux. V sekci "Odůvodnění" v POSIX AEP dokumentu je definováno, že "vláknový model POSIX.1c (se všemi zapnutými volbami, ale bez souborového systému) nejlépe odrážel současnou praxi v jistých real-time embedded oblastech. Namísto podpory plného souborového systému je pro jádra takové velikosti považována za dostatečnou pouze základní podpora I/O zařízení (read, write, open, close, control).

2.2.2 Plánování

Plánovací modul ve verzi 2 považuje plánovač a soubor real-time úloh za jeden POSIX proces s úlohami odpovídajícími POSIXovým vláknům. Na SMP systému (clusteru) můžeme mít několik paralelně běžících plánovačů a každý vypadá jako POSIX proces.

2.2.3 Posixio

RTLinux 2.0 taky přináší posixio modul, jenž poskytuje standardní rozhraní read/write/open vstupně-výstupních operací pro ovladače s POSIX stylem. Problémem pro podporu POSIXového souborového API je, že otevírání v POSIXovém souborovém systému není vnitřně v reálném čase. Otevření souboru totiž může vyžadovat neohraničené přechody prostorů jmen (unbounded traversal of the namespace), následování symbolických odkazů, rozlišování adresářů a křížení přípojných bodů. Autoři POSIX standardu naštěstí povolují velmi omezenou verzi pro otevírání. Jediné názvy cest podporované RTLinuxem jsou ve tvaru /dev/name. Jediný podporovaný mód je read/write (Yodaiken, V., Barabanov, M.).

2.2.4 Signály

Jedna oblast POSIX standardu, která ještě nebyla implementována, je požadavek asynchronních signálů.

"Signální služby jsou základní mechanismus na POSIX standardu založených systémů a jsou potřeba pro manipulaci s událostmi a řešení problémů."

Současný záměr je udělat ze signálů volitelnou součást. Užitečnost obecného signálního mechanismu v hard real-time prostředí není vůbec jasná. Účelem takového mechanismu je přerušit tok řízení vlákna a vnutit jej do rutiny obsluhující chyby a události. Real-time úlohy by měly provádět jenom jednoduché operace. Ovládání signály se tedy zdá být nesmyslné. S událostmi může být manipulováno rutinami obsluhujícími události - rutiny obsluhující hardwarová přerušení nebo funkce softwarových událostí. Pokud může událost ukončit dlouho běžící operaci, rutina obsluhující události by měla pozastavit úlohu a možná i zavolat plánovač. A co třeba chyby v plovoucí čárce? Pravidlo RTLinuxu číslo jedna praví, že ne-real-time služby by neměly být poskytovány real-time komponentami. Pokud real-time úloha používá plovoucí čárku, měla by raději explicitně kontrolovat chyby, než dovolit nejhorší případ přerušení v plovoucí čárce.

Takže real-time úlohy jsou považovány za komponentu zajišťující kompatibilitu a ne za hlavní komponentu. Na druhou stranu RTLinux nabízí mnoho signálových schopností v jiných formách.

2.3 Shrnutí

RTLinux je testovaný a ověřený hard real-time, POSIX operační systém, který používá embedded Linux jako aplikační platformu. RTCore real-time jádro, které je srdcem RTLinuxu, poskytuje celistvost, rychlou odezvu, malé odchylky od plánování (scheduling jitter) a hladký přístup k Linuxu.

Charakteristiky RTLinuxu:

• Hard real-time výkon - žádná překvapení nebo tichá selhání, jak se konfigurace systému mění s nárůstem zátěže. Krajní lhůty jsou vždy dodrženy.
• POSIX API - 1003.13 PSE51 pro real-time a plný přístup do Linuxu prone-real-time programy.
• Oddělený design - dual-kernel technologie zvedá výkon zabráněním ne-real-time procesům v překážení si s real-time procesy. Design RTLinuxu podporuje modularitu a opakované využití kódu, zatímco podává výkon omezený pouze hardwarem.
• RTLinux - kompletní vývojový systém s testovaným jádrem a souborem nástrojů, plně zapouzdřitelný, přes síť bootovatelný souborový systém. Jako obvykle jsou obsaženy veškeré věci, které jsou v Linuxu obvyklé jako např. plná podpora TCP/IP, X-Window System GUI a vývojové nástroje.

3. RTAI

3.1 Úvod

RTAI znamená Real Time Application Interface (Aplikační rozhraní v reálném čase). Nejedná se o real-time operační systém, jako například VXworks nebo QNX. Je založen na linuxovém jádře a poskytuje možnost udělat jej plně preemptivním.

Linux trpí nedostatkem podpory reálného času. K zajištění správnosti časování je nutné provést v jádře několik změn, např. v zacházení s přerušeními nebo s metodami plánování. Takto můžeme získat real-time platformu s nízkou prodlevou a plnící náročné požadavky na předvídatelnost v plném ne-real-time prostředí Linuxu (přístup k TCP/IP, grafické zobrazení a okenní systémy, souborové a databázové systémy atd.).

RTAI nabízí linuxovému jádru stejné služby přidáním vlastností real-time operačního systému. Skládá se hlavně z rozvrhovače přerušení (interrupt dispatcher): RTAI hlavně odchytává přerušení periferií a v případě nutnosti je přesměrovává do Linuxu. Není to ale přímo modifikace jádra, nýbrž přidává k jádru vlastní modul, který využívá konceptu HAL (Hardware Abstraction Layer) k získání informací z Linuxu a k zachytávání některých nezbytných funkcí. To vede k jednoduché adaptaci v linuxovém jádře, jednoduchý RTAI port z verze na verzi Linuxu a jednodušší použití jiných operačních systémů namísto RTAI. Když se neobjevuje žádná real-time aktivita, RTAI považuje Linux za úlohu běžící na pozadí.

3.1.1 Úvod do RTAI/fusion

Fusion je pokračující vývojová větev projektu RTAI, která se zaměřuje na vyplnění mezery mezi tradičním přístupem přes jádro pro dosažení omezeného chvění v nejhorších případech a dlouholeté úsilí o snížení průměrné prodlevy původního vanilla jádra Linuxu.

Prvním cílem RTAI je odsunout aplikace vyžadující real-time záruky z prostoru jádra (kernel-space), kde byly při starém způsobu přístupu s využitím pomocného jádra uzamčeny. Namísto toho jim umožňuje využít běžný linuxový programovací model v uživatelském prostoru (user-space), zatímco bude stále garantováno omezení nejhoršího zpoždění. RTAI/fusion se zaměřuje na doplnění podpory low latency pro velmi náročné real-time aplikace, které vyžadují aby maximální chvění zůstalo bez výjimky v rozsahu pár desetin mikrosekund za jakýchkoliv okolností a musí být přitom provozuschopné v uživatelském prostoru (user-space) (Dietrich, S. T., Walker, D.).

Druhý hlavní cíl RTAI/fusion je zjednodušení přechodu aplikací běžících v tradičních RTOS (jako např. VxWorks, pSOS+, VRTX a podobně) na systémy založené na Linuxu. To je možné díky poskytnutí efektivních emulací API nad RTOS abstrakční vrstvou. Jelikož je velká většina těchto systémů implementována podobným způsobem, je možné vymodelovat obecný set základních vlastností a později je podle libosti upravit pro napodobení různých API.

3.2 Časovače a přerušení

Dobrá správa časování a přerušení znamená pro systémy reálného času skutečnou výzvu. Ale jak mohu do PC časovat? Co to je přerušení, a jak jej mohu řídit? Následující text se bude vztahovat k Intel x86 architektuře.

UP (jednoprocesorová architektura) poskytuje specifický čip, který řeší problém generování přesných časových zpoždění pod softwarovou kontrolou. Je označen 8254 a je to programovatelný intervalový časovač/čítač, který může být brán jako sada čtyř I/O portů. Tři jsou nezávislé 16bitové čítače a čtvrtý je kontrolní registr pro programování módů.

RTAI poskytuje dva módy, periodický (mode 2 z 8254) a jednorázový časovač (mode 0). V jednorázovém módu jsou hodiny přeprogramovány s každým přerušením. Naproti tomu v periodickém módu je časovač naprogramován jenom na začátku a potom periodicky generuje přerušení. Je na programátorovi, který mód si pro daný úkol vybere. Periodický mód je o hodně efektivnější, pokud se má vykonávat jedna nebo mnoho úloh (ale se společnou periodou), které pravidelně vzorkují, zatímco jednorázový mód je flexibilnější, protože dovoluje časovat několik úloh bez společného dělitele časových úseků nebo spuštění některou vnější událostí. V jednorázovém módu ve RTAI je čas měřen na základě hodin procesoru a ne na čipu 8254, který je použit jenom ke generování jednorázového přerušení. To dovoluje přeprogramovat čítač pouze dvěma I/O instrukcemi, což trvá přibližně 3 ms.

3.3 Základní koncepty

RTAI/fusion definuje dva real-time módy operací pro linuxové úlohy, které ovládá:

• Primární mód garantuje velmi nízké prodlevy přenecháním kontroly real-time úlohy plánovači (co-scheduler), jehož operace nemohou být zpožděny žádnou pravidelnou aktivitou Linuxu, včetně maskování přerušení. V tomto módu se úloha jeví jako uspaná v TASK_INTERRUPTIBLE stavu, ale ve skutečnosti běží ve svém původním MMU kontextu pod kontrolou co-scheduleru. Úloha vstupuje do tohoto módu po inicializaci a pokaždé volá blokování nativní RTAI služby. Úloha tento mód opouští, aby vstoupila do sekundárního módu, jenom když vykonává standardní linuxové systémové volání. Typická plánovací zpoždění v tomto módu jsou v současné době v nejhorším případě asi 50 mikrosekund při velkém zatížení na středně výkonném x86 hardware. Některá obvyklá linuxová systémová volání mohou být obsloužena prostými doplňky RTAI. Například systémové volání na nosleep je propojeno do vysoce přesného RTAI časovače, jenž má vyšší přesnost než běžný systémový časovač a má velmi nízkou plánovací prodlevou. Úloha stále běží v primárním módu (nebo se do něj přepne), když je taková nahrazená služba zavolána (Dietrich, S. T., Walker, D.).
• Sekundární mód stále garantuje nízká zpoždění, nicméně v nejhorším případě jsou tyto hodnoty vyšší. Tento mód odkládá přerušení, která jsou zpracována Linuxem, tak dlouho dokud real-time úloha běží, aby nedošlo ke zdržení vykonávané úlohy. Poslední jmenovaná technika velmi zlepšuje předvídatelnost úloh běžících v sekundárním módu bez toho, aby nějak ovlivnily prodlevu přerušení pro ostatní úlohy operující v primárním módu.

Linuxové úlohy řízené RTAI/fusion jsou transparentně a automaticky přepínány mezi oběma módy podle úrovně real-time služby, o kterou žádají. Real-time priority jsou trvale udržovány přes tyto přesuny, takže real-time úloha řízená jádrem Linuxu by měla mít podle potřeby stále zajištěnou vyšší prioritu než ostatní úlohy, které jsou spravovány spoluplánovačem.

3.4 Software

RTAI/fusion je postaveno na vrstvě Adeos pro upřednostnění zpracování hardwarového přerušení a další implementaci způsobu spolupráce mezi real-time rozšířením a linuxovým jádrem.

Celý základ kódu RTAI/fusion se naprosto odchýlil od předcházející RTAI architektury a implementace, jelikož je založen na projektu Xenomai, který byl nedávno s RTAI sloučen. Důvodem je také konflikt s projektem RTLinux, jehož vývojáři tvrdí, že původní systém mají patentován.

3.5 Podporované architektury

RTAI/fusion v současné době běží pouze na architektuře x86 (UP a SMP), ale je také nově k dispozici port na platformu PPC (zatím jenom UP). Dodatečně vytvořil HYADES projekt RTOS jádro pro architekturu ia64 a plánuje se integrace tohoto portu, jakmile bude vydán.

V dalším díle...

Realtime preemptivní modifikace jádra: Analýza vlivů několika variant preemptivního jádra na časové odezvy procesů reálného času. Srovnání hard real-time linuxových modifikací (RTLinux, RTAI).

Diskuse k tomuto článku

[Michal Čihař]

A co Xenomai? V současné době probíhá vývoj spíš v něm než u RTAI. Myslím že také podporuje víc architektur.

[belisarivs]

Xenomai je tam zmineno. Doslo ke slouceni se RTAI. RTAI se tak odchylilo od sveho puvodniho smeru a uz nevyuziva nanojadro, ale je to jenom pridavny modul. Ten projekt se ted jemuje RTAI/fusion. Je to tam zmineno. Ale na druhou stranu jakekoliv pripominky si cenim. A taky je planuji zaclenit do svoji Bakalarske prace.

[Michal Čihař]

To je ale stará informace . Viz třeba tento mail. Xenomai 2.0 je to, co původně mělo být RTAI/fusion 1.0.

[belisarivs]

Hmm, tak to jsem nezaregistroval. Nicmene muj projekt se tykal RTLinuxu, RTAI a Realtime Preempt patche. Mel byt na 20 stran a ja ho i bez Xenomai napsal pres 30 stran dlouhy. Vsechno jsem to tam dat nemohl. Zvlaste kdyz to RTAI nebylo primarni. Pojednani o tom patchi, bude pro svou relativni obsahlost v dalsi kapitole.

[moira]

To dovoluje přeprogramovat čítač pouze dvěma I/O instrukcemi, což trvá přibližně 3 ms.

To je nejak dlouho na dve instrukce, ne?

[Pavel Píša]

Nemohu potvrdid ani vyvrátit tento odhad. Ale je si dobré uvědomit, že to co se tváří jako 8254, se nachází v southbridgi. CPU k tomu přistupuje přes IO instrukce, musí se protlouct přes rozhraní CPU north bridge, přes arbitraci s dalšími PCI zařízeními, pak se po PCI dostane do south bridge a poté do jeho části, která emuluje ISA periferie. Nejsem si jistý, jestli u některých čipsetů není dokonce 8254 až na čtyřbitové LPC (Low Pin Count) sběrnici připojené k south bridgi. Seriové kanály a paralelní port jsou někdy až na ní. Takže bych se té strašlivé době ani nedivil.

To jsou ovšem problémy dané slepencovitou architekturou PC. Na embedded zařízeních přístup k časovači takový problém není.

Protože i Intel a AMD uznali, že pro synchronizaci multimédií je toto řešení nepoužitelné, jsou novější chipsety pro PC vybaveny HPET timery, které Linux umí využít. Toto řešení by mělo být i o řády výkonější a flexibilnější než používání archeologické vykopávky, která přežila z roku 1980.

[belisarivs]

To je pravda. Ja jsem v podstate delal vycuc a preklad z anglickych materialnu, takze to muze vyt chyba vznikla pri vyrobe. Dobra poznamka. Vysledne latence se pohybuji v radech mikrosekund, a tak jsou ty 3 ms podle me spatne. Mrknu se na to. Diky za poznamku.

[Pavel Píša]

V noci jsem přehlédl to ms, nějak jsem to automaticky bral jako usec, což odpovídá mému odhadu. Ale i to je při častějším použití strašlivá doba. Při 50kHz vzorkovací frekvenci je to 18% z periody jen na přeprogramování timeru, což je strašné. Ale aplikace na 20 az 50 kHz i s 8254 chodí.

[amnesiac]

Asi je to lehce OT, ale jak je to se spravou pameti ? Mam na mysli situaci, kdy je RT Linuxem rizeno nejake vyrobni zarizeni a dojde fyzicka pamet a musi se swapovat. A jak by to vypadalo pri vycerpani i virtualni pameti ? A vypina se OOM killer ?

Diky

[Pavel Píša]

RT-Linux nevolá z kontextu real-time threadu žádné funkce pro zprávu paměti Linuxu. Funkce kmalloc a vmalloc jsou volané pouze během vytváření RT-Threadů a to je možné pouze z ne-real-time kontextu (při zavádění RT modulů, aplikací, či při zpracování nějakého volání z Linuxového user-space). Starší verze RT-Linuxu nenabízely vůbec možnost dynamické alokace paměti z real-time threadů. V rámci projektu OCERA byl navržený velmi kvalitní alokátor paměti TLSF s omezenou dobou volání a komplexitou O(1), který je nyní součástí vývojové větve RT-Linux GPL. Memory pool pro tento alokátor je však naalokován pouze při zavádění modulů RT-Linuxu a Linuxové jádro ho nemůže měnit.

Shrnutí, out of memory killer může pozabíjet i všechny aplikace běžící v Linuxovém kontextu, ale funkčnost již běžících real-time threadů tím není ovlivněna a real-time část běží například i poté, co jádro Linuxu bídně zhyne na Oops či Panic. RT část se tedy ještě může při detekci tohoto stavu postarat o bezpečné zastavení aplikace, vlaku atd.

Ještě poznámka k Posixovým signálům, RT-Linux GPL implementuje funkce pro generování i zpracování signálů. Oproti standardu však specifikuje, že signál bude řešen nad kontextem toho threadu, který ho registroval. To je pro real-time aplikace výhodnější, protože pomalé zpracování signálu nemůže náhodně zneužívat priority některého z vysoce prioritních threadů.

[nardew]

aky je vlastne rodiel medzi real time, hard real time a nereal time? prosil by som trosku take laickejsie vysvetlnenie...

dik

[belisarivs]

Tehle otazky jsem si vsimnul az ted, ale treba to bude nekoho zajimat.

Rozdil mezi real-time a nereal-time je ten, ze v real-time je snaha za kazdou cenu eliminovat nahodny vyskyt velkych prodlev.

V nerealtime se tytpo vyskytnout mohou.

Pak se real-time deli podle nasazeni na hard a soft.

Je to rozdeleni podle toho, jak vazne by mohly byt dusledky. Pokud muze dojit "pouze" ke zpomaleni provozu, je to soft. Pokud by se ale mohlo stat, ze v pripade vyskytu prodlevy dojde k urazu, poskozeni nebo zniceni neceho, je to hard realtime.

[nardew]

aky je vlastne rodiel medzi real time, hard real time a nereal time? prosil by som trosku take laickejsie vysvetlnenie...

dik