Jaderné noviny – 21. 7. 2010: Potíže s deadline plánovačem

5. 8. 2010 | Jirka Bourek | Jaderné noviny | 3304×

Aktuální verze jádra: 2.6.35-rc5. Citáty týdne: Andrew Morton. Duch z minulosti sysfs. Oprava zpětného zápisu z přímého znovuzískávání. Přidání period do SCHED_DEADLINE. Alokace spojité paměti pro ovladače.

Obsah

• Aktuální verze jádra: 2.6.35-rc5
• Citáty týdne: Andrew Morton
• Duch z minulosti sysfs
• Oprava zpětného zápisu z přímého znovuzískávání
• Přidání period do SCHED_DEADLINE
• Alokace spojité paměti pro ovladače

Aktuální verze jádra: 2.6.35-rc5

Současné vývojové jádro je stále 2.6.35-rc5; během minulého týdne nevyšla žádná -rc verze. Proud oprav ale nadále proudí do hlavní řady, také byl přejmenován kód pro blok logické paměti [logical memory blok, LMB] na „memblock“.

Aktualizace stabilních jader: Během minulého týdne žádné nevyšly.

Citáty týdne: Andrew Morton

S Rustyho patchem pro chybu v modulech a po revertu „driver core: remove CONFIG_SYSFS_DEPRECATED“ Grega Vandala-Hartmana a po smazání BUG_ON z generic_delete_inode() mám možnost se přihlásit! Dobrá, nefunguje mi síť, ale to je jen taková drobnost.

-- Andrew Morton

Duch z minulosti sysfs

napsal Jonathan Corbet, 21. července 2010

Před pár lety se zdálo, že nekompatibilní změny v sysfs pravidelně způsobují nefunkční systémy. Od té doby se ale věci zlepšily a již nějakou dobu se neobjevila žádná zpráva o nefunkčním stroji nebo vynuceném upgradu udevu. Toto zlepšení je výsledkem úmyslné snahy vývojářů věci stabilizovat a zavést pro využívání informací exportovaných přes sysfs dané postupy. Jak ale právě zjistili někteří testeři linux-next, dědictví starých problémů se sysfs se ještě úplně neztratilo.

Konfigurační volba CONFIG_SYSFS_DEPRECATED existuje jako jeden způsob potýkání se s následky významné změny v sysfs. V prvních dnech sysfs se zařízení objevovala na podivných místech, obzvláště pod /sys/class. Aby byl souborový systém konzistentnější, rozvržení bylo změněno tak, že se víc informací o zařízeních přesunulo do /sys/devices, zavedl se adresář /sys/block a tak dále. Není potřeba říkat, že taková změna je smrtící pro systémy, které očekávají staré rozvržení, takže byla přidána konfigurační volba, která toto staré rozvržení obnoví, když je to potřeba.

V roce 2010 již nikdo nedodává distribuci, která by na starém rozvržení závisela. Proto Greg Kroah-Hartman zaslal patch, který odstraňuje tuto konfigurační volbu i významné množství kódu, který ji podporuje; patch šel také do linux-next. Greg poznamenává: Žádné nástroje v uživatelském prostoru to již nepotřebují, takže je bezpečné to odstranit.

Až na to, že to možná tak bezpečné není. Andrew Morton rychle nahlásil, že jeho stroj s Fedora Core 6 bez této volby nenabootuje. Andrew je dobře známý tím, že provozuje archaické distribuce jenom proto, aby mohl přijít na takovéto problémy s kompatibilitou; dalo by se dohadovat, že o moc víc strojů s FC6 se již nepoužívá a ještě méně z nich bude chtít provozovat jádro 2.6.35. Jak ale podotkl Dave Airlie, stroje s RHEL5 také nenabootují a takových je více.

Davova rada byla prostá: Žijte se svými chybami, pánové, a nesnažte se je pohřbít. Stejně jako všichni ostatní i on ví, co to znamená žít s vlastními chybami: ABI pro grafiku obsahuje nejednu. K chybě dojít může, ale když se stane součástí ABI pro uživatelský prostor, bývá obtížné se jí zbavit. Proto jsou rozšíření ABI podrobována takovému zkoumání: Jakmile na nich někdo začne záviset, je potřeba je udržovat do nekonečna.

Oprava zpětného zápisu z přímého znovuzískávání

napsal Jonathan Corbet, 20. července 2010

„Zpětný zápis“ [writeback] je proces zapisování špinavých stránek v paměti zpět na jejich úložiště, což obvykle bývá soubor nebo swap. Správně řešený zpětný zápis je kritický jak pro výkonnost systému, tak pro integritu dat – pokud se zpětný zápis příliš opozdí oproti špinění stránek, systém se může dostat do vážných problémů s pamětí. Navíc se tím také zvětšuje objem dat, která se ztratí při pádu systému. Příliš horlivý zpětný zápis na druhou stranu může vést k nadměrné spotřebě propustnosti I/O a špatně naplánovaný zpětný zápis může významně snížit výkonnost I/O kvůli nadměrnému pohybu hlaviček disku. Jako u mnoha úloh při správě paměti i zde platí, že udělat to správně je složité cvičení zahrnující kompromisy a heuristiky.

V dubnu jsme se v Jaderných novinách dívali na specifický problém zpětného zápisu: Hodně aktivity se dělo v přímém znovuzískávání [direct reclaim]. Normálně jsou paměťové stránky znovuzískávány (tj. zpřístupněny k jinému využití tím, že se data zapíší na úložiště) na pozadí; když všechno funguje dobře, tak pokud je potřeba paměť, vždycky je k dispozici seznam volných stránek. Jestliže ale alokaci paměti nelze uspokojit ze seznamu volných, jádro se může pokusit stránky uvolnit přímo v kontextu procesu, který se o alokaci pokouší. Přechod od požadavku na alokaci k takovému pročištění se nazývá „přímé znovuzískávání“.

To normálně funguje a je to dobrý způsob, jak omezit procesy náročné na paměť, ale také má několik významných problémů. Jedním z nich je přetečení zásobníku; ke znovuzískávání může dojít téměř z jakéhokoliv místa v jádře, takže ještě předtím, než tento proces započne, může být jaderný zásobník téměř zcela zaplněný. Jestliže ale znovuzískávání potřebuje zapisovat stránky na úložiště, může začít další dlouhý řetěz volání, což nakonec vede k přetečení zásobníku. Krom toho přímé znovuzískávání, které pracuje se všemi stránkami, jež dokáže najít, většinou vytváří I/O s intenzivním pohybem hlaviček disku, což poškozuje výkonnost celého systému.

Oba tyto problémy lze pozorovat na produkčních systémech. V reakci na to se mnoho souborových systémů změnilo tak, aby jednoduše ignorovaly požadavky na zpětný zápis, které přijdou z kódu přímého znovuzískávání. Tím problém mizí, ale takové zahrabání hlavy do písku nikoho netěší; krom toho to zvyšuje riziko, že se systém dostane do stavu, kdy bude paměť zcela vyčerpána.

Mel Gorman na tomto problému příležitostně pracoval několik měsíců; jeho nejnovější sada patchů by se štěstím mohla situaci vylepšit. Změny jsou relativně malé, ale zjevně věci upravují správným způsobem.

Klíčem k řešení problému je jeho pochopení. Není tedy překvapivé, že velká část změn zpětný zápis vůbec neovlivňuje; tyto změny jsou nástroje pro sledování, které mají poskytnout informaci o tom, co kód pro znovuzískávání dělá. Nové sledovací body poskytují náhled na povahu problému a, což je důležitější, na to, jak daná změna pomůže.

Základní změna je hluboko ve smyčce přímého znovuzískávání. Jestliže se narazí na špinavou stránku, kód trochu víc přemýšlí nad tím, co s ní. Jestliže je tato stránka anonymní (data procesu), ke zpětnému zápisu dojde stejně jako dříve. Důvodem je to, že zpětný zápis takových stránek (půjdou do swapu) je jednodušší než u stránek, které patří do souborů; pro zápis anonymních stránek je také méně příležitostí. Výsledkem je, že anonymní zpětný zápis stále může způsobit problémy s posunem hlaviček – ale jenom pokud swapovací oblast sdílí disk s jinými daty.

U špinavých stránek, které patří souboru, je situace trochu odlišná: Přímé znovuzískávání se již nepokouší tyto stránky zapsat přímo. Místo toho se sestaví seznam špinavých stránek a ten se následně předá vhodnému procesu na pozadí, který se již postará o zpětný zápis. V některých případech (jako když se uvolňování po kusech [lumpy reclaim] pokouší uvolnit specifický větší kus paměti) bude kód přímého znovuzískávání čekat s nadějí, že se identifikované stránky brzy uvolní. Ve zbylých případech prostě jde dál a pokouší se najít volné stránky jinde.

Předání znovuzískávání úloze, která je k tomu určena, má svoje výhody. Je to jednoduchý způsob, jak se přepnout do jiného jaderného zásobníku – do takového, o kterém víme, že je téměř prázdný – než se vydáme na cesty zpětného zápisu. Bylo diskutováno přepínání zásobníků přímo v kódu přímého znovuzískávání, ale rozhodlo se, že jádro pro přepínání zásobníku již mechanismus má (přepínání kontextu) a v tomto případě bude nejlepší ho použít. To, že se zpětný zápis přenechá kswapd a vláknům pro zpětný zápis na dané BDI, by výkonnosti mohlo také pomoci, protože tato vlákna se pokoušejí seřadit operace tak, aby se minimalizoval pohyb hlaviček.

Když byl v dubnu tento problém diskutován, Andrew Morton upozornil na to, že postupem času objem stránek, které se zapisují na úložiště, výrazně vzrostl, což mělo negativní vliv na výkonnost systému. Chtěl, aby se někdo zamyslel nad tím, proč se tak stalo, nikoliv jak zmírnit následky. Závěrečný patch Melovy série vypadá jako pokus na to reagovat. Mění kód přímého znovuzískávání tak, že když tento kód začne narážet na špinavé stránky, šťouchne do vláken pro zpětný zápis a řekne jim, aby stránky pročišťovaly agresivněji. Jde o to, aby normální mechanismy pro zpětný zápis běžely co nejrychlejším tempem, aby kód přímého znovuzískávání nebyl zapotřebí tak často.

Toto ladění má v některých benchmarcích poměrně významný vliv; Mel říká:

Zapisování na pozadí zjevně fungovalo lépe v tom ohledu, že se stránky uvolnily včas, a zdržení způsobené přímým znovuzískáváním je škodlivé samo o sobě. Probouzení vláken na pozadí kvůli špinavým stránkám způsobilo značný rozdíl v počtu zpětně zapsaných stránek. Se všemi patchi bylo zpětně zapsáno jenom 759 stránek na souborovém systému, kdežto s vanilla jádrem to bylo 581811; celkový počet prohledávaných stránek přitom poklesl.

Každý, kdo se rád prohrabuje výsledky benchmarků, by se měl podívat na Melův e-mail, ve kterém patche zasílá – podle všeho spustil jakýkoliv test, který by mohl kvantifikovat vliv této série patchů. Pro změny tak hluboko v kódu správy paměti dává takto rozsáhlé testování smysl, protože dokonce i malé změny mohou mít na specifické zátěže výrazný vliv. V tuto chvíli se zdá, že změny mají požadovaný efekt a většina problémů s předchozí verzí byla vyřešena. Změny zpětného zápisu se možná blíží k produkčnímu nasazení.

Přidání period do SCHED_DEADLINE

napsal Jonathan Corbet, 20. července 2010

Linuxový plánovač, a to jak verze z hlavní řady, tak verze z realtime jádra, poskytuje několik plánovacích tříd pro úlohy běžící v reálném čase. Tyto třídy implementují klasickou POSIXovou sémantiku založenou na prioritách, kde je úloze o nejvyšší prioritě garantováno, že bude mít přístup k CPU. I když tento plánovač funguje tak, jak o sobě tvrdí, plánování založené na prioritách má mnoho problémů a již nějakou dobu není předmětem výzkumu. Cool plánovače jsou v tomto století založeny na časových limitech [deadline]. Linux ještě plánovač s časovým limitem nemá, ale na jednom se pracuje. Nedávná diskuze o implementaci kompletního modelu s časovým limitem opět ukázala, jak složité je udělat plánování s časovým limitem správně ve skutečném světě.

Plánování s časovým limitem se zbavuje priorit a nahrazuje se trojicí parametrů: Doba běhu v nejhorším případě [worst-case execution time] (či rozpočet [budget]), časový limit a perioda. Proces v podstatě plánovači říká, že bude potřebovat maximálně určité množství času CPU (rozpočet) do daného časového limitu, přičemž tento časový limit se může volitelně opakovat s danou periodou. Například aplikace pro zpracování videa tedy může požadovat 1 ms času CPU ke zpracování dalšího příchozího snímku, který je očekáván do 10 ms s periodou 33 ms pro další snímky. Plánování s časovým limitem je lákavé, protože umožňuje specifikovat potřeby procesu přirozeným způsobem, který není ovlivněn jiným procesem v systému. Také je velmi cenné to, že podle parametrů časového limitu lze garantovat, že proces svůj limit stihne – jakýkoliv proces, který by mohl způsobit, že jiný nestihne svůj limit, je odmítnut.

Plánovač SCHED_DEADLINE, který vyvíjí Dario Faggioli, se zdá být na cestě k eventuálnímu začlenění do hlavní řady, i když nikdo ještě nebyl tak bláhový, aby pro tento konkrétní úkol stanovil časový limit. Tento plánovač funguje, ale prozatím používá jednu zkratku: Předpokládá, že perioda a časový limit jsou stejné. Toto zjednodušení zjednodušuje „test pro přijetí“ – rozhodnutí, jestli přijmout další úlohu SCHED_DEADLINE. Každý proces dostane parametr „propustnost“, což je poměr mezi rozpočtem CPU a hodnotou časového limitu/periody. Dokud součet propustností všech procesů na daném CPU nepřekročí 1.0, plánovač může garantovat, že se časové limity stihnou.

Jak Dario nedávno řekl na linux-kernel, existují uživatelé, kteří by rádi specifikovali různé hodnoty časového limitu a periody. Úprava plánovače, aby tuto sémantiku implementoval, není nijak složitá. Vytvořit test pro přijetí, který bude stále zajišťovat, že se stihnou limity, už je ale těžší. Jakmile jsou perioda a časový limit odděleny, procesy nemusí stihnout své limity, i když propustnost CPU není využita naplno.

Jak k tomu může dojít, můžeme vidět v příkladu, který Dario zaslal. Představme si proces, který s periodou 10 ms potřebuje 4 ms času CPU a má časový limit 5 ms. Časová osa toho, jak takový proces může být plánován, vypadá takto:

Zde je plánovač schopen spustit proces do limitu; do konce zbývá 1 ms navíc. Když ale nyní přijde další proces se stejnými požadavky, výsledky už nebudou tak dobré:

Přestože se 20 % času CPU nevyužívá, proces P2 svůj limit nestihne o 3 ms. Ve skutečné situaci běhu v reálném čase může být toto zpoždění katastrofální; plánovač by zjevně měl P2 v takové situaci odmítnout. Problém je, že detekce takového problému není jednoduchá, obzvláště vzhledem k tomu, že od plánovače se (rozumně) očekává, že nechá nějaký čas CPU aplikacím a nespotřebuje ho všechen na složité výpočty o přijetí procesu. Z tohoto důvodu jsou algoritmy pro rozhodnutí o přijetí předmětem výzkumu v akademické sféře. Příklady toho, jak složité mohou být, vizte v v tomto pojednání [PDF], jehož autorem je Alejandro Masrur et al. nebo v tomto od Marka Bertogna [PDF].

Je několik způsobů, jak problém zjednodušit. Jedním z nich by bylo změnit výpočet propustnosti tak, aby byl poměrem mezi rozpočtem CPU a relativním časem do časového limitu (místo poměru rozpočtu a periody). Například u příkladu výše by měl každý proces propustnost 0,8; plánovač by tak zjistil, že s druhým procesem by součet vyskočil na 1,6, a úlohu odmítl. S tímto výpočtem by plánovač opět mohl garantovat, že se časové limity stihnou, ale za určitou cenu: Tento vzorec způsobí odmítnutí procesů, které by ve skutečnosti bylo možné naplánovat bez obtíží. Je to příliš pesimistická heuristika, která zabrání plnému využití dostupných zdrojů.

Alternativa, kterou navrhl Dario, je zůstat při přijímání úloh u propustnosti založené na periodě s rizikem, že se některé limity nestihnou. V tomto případě by zodpovědnost za to, že bude možné všechny úlohy v systému naplánovat, přebírali vývojáři v uživatelském prostoru. Trochu potěšit by je mohlo to, že období, o které se nestihne časový limit, je deterministicky omezené, protože nebude překročena celková propustnost CPU.

Tento nápad nepřežil střet s Peterem Zijlstrou, který si myslí, že to zlikviduje všechno, co se od plánovače s časovým limitem očekává:

Hlavní důvod, proč SCHED_FIFO a přátelé tak moc stojí za prd, je, že neposkytují žádnou izolaci, a jako abstrakce operačního systému jsou tedy naprosto k ničemu. Jestliže odstraníš kontrolu přijetí, skončíš v podobné situaci.

Peter navrhl, aby se plánování podle časového limitu logicky rozdělilo na dva různé plánovače. Tvrdý [hard] plánovač v reálném čase by si ponechal nejvyšší prioritu a vyžadoval by, aby hodnoty časového limitu a periody byly stejné. Pokud by někdy v budoucnu byl vyvinut vhodný kontrolor přijetí, tento požadavek by bylo možné zmírnit, pokud by stále bylo možné garantovat vyhovění časovým limitům.

Pod tvrdým plánovačem by byl měkký [soft] plánovač, který by měl přístup k (většině) času CPU, který nevyužil tvrdý plánovač. Takový plánovač by mohl přijímat procesy podle propustnosti založené na periodě s tím, že by bylo explicitně dáno, že nemusí o omezené množství času stihnout časový limit. Měkký plánovač pro běh v reálném čase je pro velký počet aplikací dostatečně dobrý, takže není důvod ho nenabídnout, když tím nebude postižen tvrdý plánovač.

Věci tedy pravděpodobně půjdou touto cestou, i když na skutečný tvar řešení si budeme muset počkat, než Dario zašle další verzi patche SCHED_DEADLINE. Nicméně i poté, co bude tento problém vyřešen, zbývá pro plánování s časovým limitem mnoho dalších problémů, které bude potřeba překonat, přičemž na čelních příčkách seznamu je výkonnost na větším počtu jader. Takže i když Linux téměř určitě bude někdy takový plánovač mít, stále je těžké říci, kdy by to tak mohlo být.

(Čtenáři, které zajímá průnik akademické práce s prací praktickou, si mohou prostudovat nedávno vydané zápisy [PDF] z konference OSPERT 2010, která se začátkem července konala v Bruselu.)

Alokace spojité paměti pro ovladače

napsal Jonathan Corbet, 21. července 2010

Alokace fyzicky spojitých paměťových bufferů je něco, co potřebuje mnoho ovladačů zařízení, ale co nelze na déle běžícím linuxovém systému spolehlivě zajistit. To vede ke všem možným neuspokojivým obezličkám v základním kódu ovladačů. Patche spojitého alokátoru paměti, které nedávno zaslal Michal Nazarewicz, jsou pokusem vyřešit tento problém konzistentně pro všechny ovladače.

Před několika lety, když autor tohoto článku psal ovladač pro kameru na původním systému OLPC XO, se objevil problém. Hardware byl sice schopen kopírovat snímky videa do paměti pomocí DMA, ale pouze do fyzicky spojitých bufferů. Jinými slovy tento (levný) DMA engine neuměl DMA rozsyp/sesbírej [scatter/gather]. To vynutilo volbu: Buď alokovat paměť pro zachytávání videa při bootu, nebo se ji pokusit alokovat za běhu, když se kamera použije. První možnost je spolehlivá, ale má nevýhodu, protože, když se kamera nepoužívá – tj. ve většině případů, významný kus paměti zůstává nečinně ležet (na systému, který má paměti nedostatek). Druhá volba pamětí neplýtvá, ale není spolehlivá – alokace velkých spojitých oblastí jsou tím složitější, čím víc se paměť fragmentuje. V případě OLPC došlo na první možnost, obětovala se paměť, aby kamera fungovala vždy.

Na tento konkrétní problém narazilo během let mnoho vývojářů; každý autor ovladače má tendence vymyslet nějaké ad hoc řešení, které v danou chvíli dává smysl. Několik let pomáhal patch „bigphysarea“, ale ten nikdy nebyl vložen do hlavní řady a již nějaký čas se neudržuje. Obecně tedy problém zůstává nevyřešen.

Patche pro spojitou alokaci paměti [contiguous memory allocation, CMA] představují pokus dát dohromady flexibilní řešení, které by mohly použít všechny ovladače. Základní technika bude povědomá: CMA si při bootu (když je jí spousta) zabere kus spojité fyzické paměti a pak ji přiděluje ovladačům. V čem se hlavně odlišuje, je propracovaný mechanismus, který definuje rezervované regiony paměti a politiky, s jakými jsou přidělovány.

Systém, který používá CMA, bude vždy vyžadovat alespoň jeden bootovací parametr, který popíše region(y) paměti a politiku pro přidělování. Syntaxe je poněkud složitá, takže velkou část patche tvoří kód, který ji analyzuje; všechny detaily vizte v souboru Documentation/cma.txt. Jednoduchý příklad nastavení CMA na příkazové řádce by mohl vypadat nějak takto:

cma=c=10M cma_map=camera=c

To definuje region o velikosti 10 MB (nazvaný „c“) a nastaví, že požadavky na alokaci zařízením camera mají být uspokojeny z něj. Lze nastavit více oblastí, každé nastavit vlastní velikost, zarovnání a alokační algoritmus. Oblasti lze také rozdělit na různé „druhy“ [kind] – „druhy“ lze použít k oddělení velkých a malých alokací nebo k ukládání různých bufferů do různých DMA zón či NUMA uzlů. Složitější příkazové řádky připomínají regulární výrazy a jsou hůře čitelné. Účelem této složitosti je umožnit velkou flexibilitu toho, jak se s pamětí pracuje, bez potřeby měnit ovladače, které s touto pamětí pracují. Jestli tato flexibilita stojí za náklady, není úplně jasné (přinejmenším autorovi článku).

Ovladač může alokovat kus paměti voláním:

#include <linux/cma.h>

unsigned long cma_alloc(const struct device *dev, const char *kind,
                        unsigned long size, unsigned long alignment);

Jestliže všechno proběhne správně, návratová hodnota je fyzická adresa alokované oblasti paměti.

Z důvodů, které nejsou úplně jasné, je s buffery alokovanými pomocí CMA spojen čítač odkazů. S tímto počet manipulují dvě funkce:

int cma_get(unsigned long addr);
int cma_put(unsigned long addr);

Vzhledem k tomu, že se používá čítání odkazů, neexistuje funkce cma_free(); místo toho se kus paměti předá cma_put() a uvolní se interně, když počet odkazů klesne na nulu.

CMA obsahuje alokátor best-fit (nejvíce vyhovující umístění), ale je navrženo tak, aby fungovalo s více interními alokátory. Pokud by tedy bylo potřeba použít jiný algoritmus pro alokace, jeho přidání do systému je opravdu přímočará záležitost. Syntaxe pro příkazovou řádku samozřejmě nabízí způsob, jak nastavit, který alokátor se pro kterou oblast má používat.

Ve shrnutí: CMA nabízí řešení problémů, se kterými se autoři ovladačů potýkají již několik let. Autor článku má však podezření, že než bude možné uvažovat o začlenění do hlavní řady, bude zapotřebí nějakých změn. Složitost tohoto řešení je pravděpodobně větší, než tato situace vyžaduje, a celá ta věc by mohla těžit z integrace s infrastrukturou mapování DMA. Jednoho dne by ale bylo pěkné začlenit řešení problému s velkými buffery takovým způsobem, který budou moci používat všechny ovladače.

       

Komentáře

[Bedňa]

S týmito novými nadpismi v JN to myslím bude prehľadnejšie, keď človek niečo hľadá. Pekný článok.

[peto]

Ta idea Petra Zijlstru (clovek, ktory mi pripomienkoval analyzu predmetu, ktory budem prednast od oktobrar/rijna)mi od vcera pripada a ako vyriesena este lepsie, ako navrhuje on

IRMOS planovat je super napad... http://lwn.net/SubscriberLink/398470/3d16ea755dd71ba7/

[trekker.dk]

a) nadpis moc neodpovídá obsahu článku, ke kterému se vztahuje (vývoj něčeho znamená potíže?)

b) v JN jsou čtyři články, ale nadpis se týká jenom jednoho. To určitě bude přehlednější, když budeš něco hledat podle nadpisu, který kompletně ignoruje to, co hledáš.

[Bedňa]

Tiež som nad tým rozmýšlal, ale nadpis by bol moc dlhý. Myslím že nadpis je preto taký, že plánovač sa aktuálne rieši a to ostatné sú len fjučúry čo sa ešte len budú riešiť.