Sched_setscheduler(2) a přátelé vám umožňují používat dva různé měkké plánovače v reálném čase, SCHED_FIFO SCHED_RR. Procesy běžící pod těmito plánovači mají vyšší prioritu než běžné procesy. Takže pokud máte jen několik těchto procesů a ovládáte priority mezi nimi, můžete ve skutečnosti získat docela sestupné odpovědi v reálném čase.
Jak bylo požadováno v komentáři, zde je rozdíl mezi SCHED_FIFO a SCHED_RR:
S plánovači v "reálném čase" existuje až 100 různých priorit (POSIX vyžaduje pouze 32 různých úrovní, takže k získání skutečného počtu byste měli použít sched_get_priority_min(2) a sched_get_priority_max(2). Oba plánovače pracují na principu preemptování procesů a vlákna s nižší prioritou, rozdíl je v tom, jak zpracovávají úlohy se stejnou prioritou.
SCHED_FIFO, je plánovač typu first in first out (odtud název). To znamená, že úloha, která narazí na frontu běhu jako první, může běžet, dokud není dokončena, dobrovolně se nevzdá svého místa ve frontě běhu nebo není vyřazena z úlohy s vyšší prioritou.
SCHED_RR, je kruhový plánovač. To znamená, že úlohy se stejnou prioritou mohou běžet pouze po určitou dobu. Pokud úloha stále běží, když vyprší toto časové kvantum, úloha je preemptována a další úloha ve frontě běhu (se stejnou prioritou) může běžet až do svého časového kvanta. Stejně jako u SCHED_FIFO mají úlohy s vyšší prioritou přednost před úlohami s nižší prioritou, ale když je znovu povoleno spustit úlohu, která byla preemptována úlohou s vyšší prioritou, pak je povoleno běžet pouze po dobu zbývající v jejím kvantu. Jak nastavit kvantum času pro úkol, viz část Noes v sched_rr_get_interval(2).
MRG
Sub-milisekundy bude těžké zaručit na jádře bez RT. Vím, že za poslední roky se udělalo mnoho velmi dobré práce (např. zmizel velký zámek jádra), ale to stále nestačí, aby to bylo zaručeno.
Mohli byste se podívat na Scientific Linux od těch přátelských atomů z CERNu a Fermilabu. To může mít nainstalováno MRG (viz můj odkaz), což vám poskytne předbalení patche PREEMPT_RT.
Nebo pokud máte peníze, můžete získat Redhat MRG. Jedná se o plně podporované linuxové distro s vestavěným patchem PREEMPT-RT, takže by to odstranilo problémové záplatování jádra.
Věc je, že Redhat si účtuje hodně za to (3000 USD ZA ROK NA INSTALACI). Myslím, že přišli na to, že jedním z největších zákazníků jsou investoři vysokorychlostního obchodování, kteří stále mají hodně a hodně dolarů, a tak si nevšimnou, že 3000 $/box/rok vyjde ven.
Jak jsem se dostal k MRG
S MRG jsem odvedl kus práce (pomocí obou výše uvedených) a je to docela dobré. Nahrazuje obslužné rutiny přerušení v základním jádře vlákny pro obsluhu přerušení. To znamená, že můžete spouštět svůj software s prioritami vyššími než vlákna IRQ! To je věc, kterou musíte udělat, pokud se chcete přiblížit záruce nižší než milisekundová latence vaší aplikace.
Zdá se, že dochází k postupnému přesunu věcí MRG do jádra hlavní řady, což je podle mého názoru dobrá věc. Možná se jednoho dne stane hlavní věcí.
Další problémy
Moderní řízení teploty procesoru může být opravdovou bolestí v krku. Měl jsem systémy, které se zablokovaly na 0,3 sekundy, když bylo obsluhováno přerušení správy systému (bleedin' BIOS, ne OS), jen proto, že se CPU trochu zahřál. Viz toto. Musíte si tedy dávat pozor na to, co dělá váš základní hardware. Obecně se musíte začít starat o to, že se zbavíte řízeného chlazení moderních počítačů, a vrátit se k velkému ventilátoru, který se neustále rychle točí.
S Linuxem se můžete dostat docela daleko, když odstraníte 'rušení' z jiných procesů až do procesu v reálném čase. Hrál jsem si se stejnou věcí ve Windows, což je mnohem větší hrůza, ale ukazuje směr. Takže jakýsi check-list:
- To nejdůležitější (podivné, ale pravdivé):hardware. Nechoďte pro notebook, ten bude optimalizován tak, aby dělal podivné věci během přerušení SMM. Nemůžete nic dělat.
- Ovladače:Linux (a Windows) má špatné ovladače a dobré ovladače. Souvisí s hardwarem. A existuje pouze jeden způsob, jak to zjistit:benchmarking.
Izolovat od zbytku systému, zakázat veškeré sdílení:
- Izolujte jeden procesor (
man cpuset). Vytvořte dvě sady CPU, jednu pro normální procesy a jednu pro váš proces v reálném čase. - Omezte část kódu v reálném čase na minimum. Komunikujte pomocí velké vyrovnávací paměti s ostatními částmi systému. Snižte IO na minimum (protože IO má špatné záruky).
- Zajistěte, aby měl proces nejvyšší (měkkou) prioritu v reálném čase.
- Zakažte HyperThreading (nechcete sdílet)
- předem přidělte paměť, kterou potřebujete, a pomocí funkce mlock() paměť.
- Izolujte zařízení, která používáte. Začněte tím, že zařízení přidělíte vyhrazené IRQ (přesuňte ostatní zařízení na jiné IRQ nebo odeberte jiná zařízení/ovladače).
- Izolujte IO, kterou používáte.
Snížit aktivitu zbytku systému:
- spouštějte pouze procesy, které skutečně potřebujete.
- odeberte hardware, který nepotřebujete, jako jsou disky a další hardware.
- zakázat výměnu.
- nepoužívejte moduly jádra Linuxu ani je nenahrávejte předem. Počátek modulů je nepředvídatelný.
- nejlépe také odebrat uživatele :)
Udělejte to stabilní a reprodukovatelné:
- zakázat veškeré úspory energie. Po celou dobu chcete stejný výkon.
- zkontrolujte všechna nastavení systému BIOS a odstraňte z nich všechny „události“ a „sdílení“. Takže žádné přepychové překročení rychlosti, teplotní management atd. Zvolte nízkou latenci, nevybírejte věci s 'burst' v názvu, protože to obecně vyměňuje propustnost za horší výkon.
- zkontrolujte nastavení ovladače pro Linux a snižte latence (pokud je to možné).
- použijte nejnovější jádro, které se každý den snaží vypadat jako jádro v reálném čase o něco více.
A poté srovnávejte pomocí zátěžového testování a ponechejte stroj zapnutý několik dní a zaznamenávejte max. latence.
Takže:hodně štěstí :)