helenos-xhci team mailing list archive

[Petr Mánek <petr.manek@xxxxxx>]

Ahoj!,

Dne 3. října 2017 12:07 Ondřej Hlavatý <aearsis@xxxxxxxx> napsal(a):
>
> 1) Vytvořit thread/fibril pool konstantní velikosti, který bude
>    obsluhovat top-half události. Implementace jednoduchá, stačí k tomu
>    nějaká fronta, do které zkopírujeme TRB o výsledku eventu. Nevýhodou
>    je, že pokud hloubka čekání na jiný výsledek v součtu přesáhne
>    velikost poolu, máme tu deadlock. Pokud využijeme thready, pak
>    vyžaduje synchronizaci a tím úpravu existujících struktur, aby byly
>    thread-safe. Odměnou však bude paralelismus ve zpracování událostí.
>
​Tato věc vypadá rozumně z implementačního o výkonnostního hlediska.
Paralelismus je navíc hodně lákavá věc při zpracování příkazů. Jedinou
potíží je ten deadlock při vyčerpání kapacity poolu. Tomu se dá vyhnout
například adaptivním zvyšováním kapacity poolu při konzistentně vyšším
vytížení za jednotku času. Pokud se to však neudělá šetrně, vyruší se tím
výhoda rozumného výkonu.

Jako nápad bych to neodepisoval, ale je nutné promyslet tento jeden
okrajový scénář.​


> 2) Kvůli každému typu eventu vytvořit vlákno, které obsluhuje tento
>    kontrétní event. Náladu trochu kazí opět port status change, ve
>    kterém je potřeba zrestartovat port, a tedy čekat na další port
>    status change. Nicméně tuto situaci lze vyřešit rozdělením
>    a zapamatováním stavu u portu. Nevýhoda je jasná, událostí je poměrně
>    hodně. Lze se však omezit na "těžkotonážní" události, a tím počet
>    vláken zredukovat. Vyžaduje synchronizaci.
>
​Tohle se mi nelíbí. Bude toho hromada implementační práce a až to
slavnostně odladíme, ukáže se, že každé vlákno/fibril 99% času stejně
neslouží žádnému kloudnému účelu a spí. Proto by ta redukce dávala smysl.
Potom ale už nebude jasný ani návrh, ani účel, a až k tomu někdo za 5 let
přijde, vygooglí si nás jen aby nám nafackoval za ten nepořádek. :D


> 3) Vytvořit fibril pro každou událost tohoto typu, tedy místo okamžitého
>    řešení události vytvořit fibril, který ji obslouží. Události jsou
>    označeny za vyřešené okamžitě, fibrily se pak budou postupně
>    probouzet a blokovat na čekání. Tím se uvolní prostor pro obsluhu
>    dalších událostí v původním fibrilu. Jednoduchá implementace. Můžeme
>    si však dovolit vytvářet fibril při každé významnější události?
>    Výhodou je, že toto řešení nevyžaduje synchronizaci, dokud se fibrily
>    přeplánovávají pouze explicitně.
>
​Vytváření vlákna při každé datové události je celkem overhead (i když
nevím, jak moc to vadí u mikrokernelu jako je HelenOS). Tato varianta mi
připadá jako​ speciální degenerovaný případ varianty č. 1, kdy bychom
špatně odhadli nafukování poolu při velké zátěži.


> 4) Inspirovat se tím, co dělá například Fuchsia, a v podstatě
>    reimplementovat lightweight fibrily - mít frontu handlerů, které se
>    postupně spouští, ověří podmínky pro běh, a pokud nejsou splněny,
>    naplánují se na konec fronty. Fronta se spouští, když dojde k eventu.
>    Nevýhodou je, že kód pro obsluhu událostí se musí rozdělit do fází,
>    které se plánují do front. V zásadě se pak musí místo
>    synchronizačních primitiv používat odplánování, a tím si primitiva
>    implementovat pokaždé "ručně". Ale je to dobré řešení z hlediska výkonu.
>
​Tato varianta se mi asi líbí ze všeho nejvíc. Vadí mi ale myšlenka, že
bychom si synchronizaci museli implementovat (a odladit!!!) sami znovu.
Nešlo by to nějak obejít?​

5) Řešit konkrétně port status change event tím, že vytvoříme fibril pro
>    každý obsluhovaný port. To významně usnadní psaní kódu pro tuto část
>    roothubu - celý stavový automat pak lze napsat jako jednu funkci,
>    která v nečinnosti blokuje, a stav si udržuje implicitně stavem
>    fibrilu. Nevýhodou je však menší robustnost - možná nekonzistence
>    stavu automatu a skutečného stavu portu. Pokud si stav zjišťujeme
>    z HW při začátku obsluhy, máme větší šanci, že se tomuto vyhneme.
>
​To mi připadá jako odsunování příčiny problému do budoucnosti. Pokud jsme
si jistí, že podobný problém už znovu nenastane, dává to smysl. V opačném
případě se touto variantou vystavujeme riziku, že budeme muset udělat
podobný "úskok stranou" kdykoliv narazíme na problém podobného ražení. Po
2-3 opakováních se opět dostaneme do spaghetti situace. Možná by proto
dávalo smysl vyřešit problém obecně a neriskovat.
​
Petr

--  <https://help.launchpad.net/ListHelp>
Petr Mánek <https://help.launchpad.net/ListHelp>
+420 606 879 752 <https://help.launchpad.net/ListHelp>
petr.manek@xxxxxx
http://petrmanek.cz