Jaderné noviny – 15. 9. 2010: D-Bus v jádře?

4. 10. 2010 | Jirka Bourek | 3938×

Aktuální verze jádra: 2.6.36-rc4. Citáty týdne: Andrew Morton, John Linville, David Woodhouse. Broadcom vydává otevřený ovladač pro své bezdrátové čipsety. Občan Linus. Nový kombinovaný strom pro úložné subsystémy. Zlepšení latence plánovače. Dynamické omezování zpětného zápisu. Rychlé zasílání zpráv mezi procesy.

Obsah

• Aktuální verze jádra: 2.6.36-rc4
• Citáty týdne: Andrew Morton, John Linville, David Woodhouse
• Broadcom vydává otevřený ovladač pro své bezdrátové čipsety
• Občan Linus
• Nový kombinovaný strom pro úložné subsystémy
• Zlepšení latence plánovače
• Dynamické omezování zpětného zápisu
• Rychlé zasílání zpráv mezi procesy

Aktuální verze jádra: 2.6.36-rc4

Současné vývojové jádro je stále 2.6.36-rc4 vydané 12. září. Nic nevyniká, ale ve vývoji GPU bylo trochu rušněji, než bych v tomhle okamžiku rád viděl (jak u Radeonu, tak u i915.) To by ale snad měla být jenom stabilizace. Také jsou nějaké změny interakce PCIe/firmware, které by měly opravit víc věcí, než rozbijí. Zkrácený changelog je v oznámení, všechny detaily najdete v kompletním changelogu.

Stabilní aktualizace: 13. září byla vydána aktualizace 2.6.34.7. Opravuje jedinou chybu, kdy mnoho uživatelů hlásilo, že jejich USB zařízení nefungují správně. Někdy se jenom ztrácely úhozy na klávesnici, jindy X odmítalo nastartovat s tím, že nemůže správně komunikovat s tablety.

Citáty týdne: Andrew Morton, John Linville, David Woodhouse

Lidé, kterým vadí neočekávané cc, by se měli zamyslet. Nebo dostat pár facek.

-- Andrew Morton

Každopádně každý, o kom vím, že revidoval kód nově uvolněného ovladače Broadcom, je nyní v nemocnici s rakovinou očí, takže v F-14 bych ho neočekával.

-- John Linville

Mezitím lidé klidně dodávají ‚špatný‘ ovladač b43 po celém světě, aniž by měli jakékoliv problémy s úřady. A přesto se právníci Broadcomu podle všeho stále drží své fantazie, že je hacknutelný otevřený ovladač staví do většího rizika, než úplně stejně hacknutelný uzavřený ovladač.

Opravování chyb a zlepšování uzavřeného ovladače je samozřejmě mnohem těžší než u otevřeného ovladače – ale když chcete jenom odstranit omezení dostupných kanálů či ladit věci, jako je vysílací výkon, u uzavřených ovladačů je to ve skutečnosti velmi jednoduché. Proto říkám ‚úplně stejně hacknutelný‘.

-- David Woodhouse

Broadcom vydává otevřený ovladač pro své bezdrátové čipsety

Broadcom – dlouho považovaný u bezdrátového síťování za velkou výspu proprietárních ovladačů – oznámil dostupnost plně otevřeného ovladače pro své čipové sady 802.11n. Ovladač, i když se na něm stále pracuje, je vydán se všemi zdrojovými kódy a používá nativní stack mac80211. Podporuje několik současných čipů (BCM4313, BCM43224, BCM43225) a poskytuje framework pro podporu budoucích čipů včetně zabudovaných čipů používajících mac80211. Zezačátku půjde do stromu staging. (Díky Luisovi Rodriguezovi.)

Občan Linus

Uprostřed technické diskuze Linusu Torvaldsovi uteklo, že se právě stal občanem Spojených Států. Zdá se, že teď právě nemůže testovat patche, protože se šel registrovat k volbám.

Nový kombinovaný strom pro úložné subsystémy

napsal Jake Edge, 15. září 2010

Jedním z výsledků letošního Linux Storage and Filesystem summitu byl plán vytvořit kombinovaný strom, který by pomohl zjednodušit proces integrace změn různých úložných subsystémů. Na summitu se James Bottomley „nabídl“, že takový strom vytvoří, což 10. září přineslo ovoce v podobě oznámení vzniku daného stromu. Paralelně k diskuzi na summitu se tu stále ještě objevuje tvrzení, že možná bude zapotřebí víc než jeden automaticky generovaný strom.

Strom v současnosti sbírá patche z několika subsystémových stromů: scsi, libata a blokového společně s patchi z quiltového repozitáře dm. Automaticky se do něj přetahuje v noci a pak je přeložen, podobně jako linux-next. Také se bude denně měnit základní bod oproti hlavní řadě, takže se bude jaderným vývojářům trochu hůře používat – také podobně jako linux-next. Kvůli tomu si Dave Chinner myslí, že nebude příliš užitečný: Opravdu si nemyslím, že strom jako tenhle bude šířeji používán – pokud bych si chtěl užívat problémy se změnou základního bodu oproti slučovacím stromům, které se denně zahazují, tak už bych používal linux-next.

James tuto stížnost vzal na vědomí a poznamenal, že linux-next byl na summitu zvažován, ale pak upozornil, že strom storage je mnohem menší cíl než linux-next: Diff oproti hlavní řadě je v současném úložném stromu stále menší než megabyte. James také poznamenal, že účastníci summitu byli trochu skeptičtí vůči stromu bez „správce úložiště“, který by na něj dohlížel (podobně jako je tomu u síťového stromu Davida Millera); takový strom možná problém nevyřeší, což mimo jiné také patřilo mezi Daveovy námitky.

Jsou tu ale také politické záležitosti, které je potřeba uvážit. Na rozdíl od sítí úložiště nikdy neměla jediného správce, takže je to trochu političtější než prostě prohlásit, že „takhle to bude“, říká James. Davidův názor je, že summit je tím nejzjevnějším místem, kde by se mělo rozhodnout o ustavení správce, i když nebyli přítomni všichni současní vývojáři úložných subsystémů. Je ale zjevné, že ti přítomní chtěli postupovat pomalu, což James popsal takto:

Takovou věc nelze rozhodnout vydáním dekretu. Pokud nebudou všichni zúčastnění souhlasit, musíš předvést, proč je to potřeba. Takže vytvořit testovací strom a zkusit, kolik problémů vyřeší, vypadá jako rozumný první krok.

Strom je k dispozici na adrese git://git.kernel.org/pub/scm/linux/kernel/git/jejb/storage-tree. Noční diffy oproti hlavní řadě a záznam přetahovacího skriptu jsou k dispozici také. Pravděpodobně bude chvíli trvat, než zjistíme, jestli úložný strom vyřeší problémy s integrací a se změnami, které zasahují do několika úložných subsystémů, ale poskytne k tomu dobrý první krok.

Zlepšení latence plánovače

napsal Jonathan Corbet, 14. září 2010

Úroveň interaktivity reakcí jaderného plánovače CPU je předmětem nekonečných debat a ladění. Je to jeden z problémů, který podle všeho nikdy nebude vyřešen ke spokojenosti všech. Nedávné diskuze na toto téma ovšem ukázaly, že i po tolika letech lze najít nízko visící ovoce; je to jenom záležitost toho přitáhnout pozornost na správné místo.

Plánovač CFS dělí čas na periody, během kterých se od každého procesu očekává, že poběží jednou. Délka periody tedy určuje maximální dobu čekání, kterou může proces očekávat předtím, než bude spuštěn – maximální latenci. Tato délka je ve výchozím nastavení 6 ms. Pokud běží dva procesy, bude perioda rozdělena nějak takto:

To samozřejmě předpokládá, že oba procesy pracují pouze s CPU, mají stejnou prioritu a nic jiného nenaruší situaci. Pokud přibude třetí proces, který pracuje pouze s CPU, perioda se dělí na ještě menší kousky:

Tento proces, při kterém plánovač dělí periodu na menší a menší kusy, ale nemůže pokračovat donekonečna. Každé přepnutí kontextu má svou cenu spočívající v režii operačního systému a chování cache; příliš časté přepínání bude mít měřitelný dopad na celkovou propustnost systému. Současný plánovač ve výchozím nastavení za hranici prohlásí 2 ms – jestliže má jít časový díl přidělený jednomu procesu pod tuto dobu, přistoupí se místo toho k prodloužení periody. Takže pokud se objeví ještě jeden náročný proces, výsledkem bude:

Jinými slovy, když roste vytížení, jádro začne obětovat latenci, aby zachovalo propustnost. V situacích, kdy je zátěž poměrně velká (často je zmiňován překlad jádra s mnoha paralelními procesy), mohou latence narůst do té míry, že to uživatele opravdu štve. Mathieu Desnoyers s rozhodl, že situaci napraví tímto patchem, který se pokouší zmenšit minimální možnou délku časového dílu, dokud není více než osm běžících procesů; tímto způsobem doufal, že zlepší latenci na vytíženějších systémech.

Jeho patch obsahoval nějaké výsledky testů, které ukázaly, že maximální latence se snížily přibližně na polovinu. I tak ale Peter Zijlstra patch zahodil s tím, že to není nijak okouzlující, vypadá to jako náhodná změna bez konceptuální celistvosti. Za to si vysloužil jemné pokárání od Linuse, který má pocit, že výkonnost jádra, co se latencí týče, není tak dobrá, jak by mohla být. Poté diskuze ještě chvíli pokračovala k zajímavému závěru, že všichni měli částečně pravdu.

Mathieův patch byl založen na poněkud chybném pochopení toho, jak se počítají periody plánovače, takže patch nedělal úplně to, co očekával. Od správců plánovače tedy bylo správné, že ho odmítli. Patch ale latence zlepšil. Ukázalo se, že změna, na které ve skutečnosti záleželo, bylo zkrácení minimálního časového dílu z 2 ms na 750 µs. To plánovači umožňuje dodržet stejnou periodu i při osmi procesech a pak to zpomaluje její prodlužování. Výsledkem jsou lepší výsledky při měření latance a zdá se, že i hezčí pocit při interaktivní práci. Patch, který pouze měnil minimální délku dílku byl rychle začleněn do hlavní řady a bude přítomen v 2.6.36-rc5. Zajímavé je, že i přes obavy, že kratší díl poškodí propustnost, nebyl tento patch zatím příliš benchmarkován.

Zde se ale věci nezastavily. Jeden z Mathieuových testů používal příznak SIGEV_THREAD funkce timer_create(), takže se pro každou událost vytvářelo nové vlákno. Zdá se, že tomuto vláknu trvá dlouho, než se dostane k CPU – viníkem je podle všeho kód, který se pokouší vyvážit přístup k CPU mezi nově vytvořeným potomkem a jeho rodičem; tento kus kódu byl problematický již v minulosti. Mike Galbraith upozornil, že vlastnost plánovače nazvaná START_DEBIT – která odkládá první spuštění úlohy na další periodu – má na latenci nepříjemný vliv. Vypnutí této vlastnosti věci významně zlepšuje, ale cenu za to lze pocítit jinde v systému. Konkrétně to umožňuje zátěžím, které intenzivně používají fork(), nepříznivě ovlivnit jiné procesy.

Mathieu zaslal patch, který přidává novou vlastnost nazvanou START_NICE; když je povolena, oba procesy, které se vrátí z fork(), mají na jednu periodu plánovače sníženou prioritu. S touto penalizací lze oběma procesům umožnit spuštění v současné periodě a jejich vliv na zbytek systému je přesto omezen. S tím spojený benchmark ukazuje po této změně výrazné zlepšení.

Mezitím Peter na chvíli z diskuze zmizel a vrátil se s poněkud komplexnějším patchem, který předvádí jiný přístup. Nové úlohy jsou stále vkládány na konec fronty, aby se zajistilo, že existující procesy nebudou obrány o své současné časové díly. Pokud je ale zapnuta nová vlastnost DEADLINE, každá nová úloha také obdrží časový limit nastavený o jednu periodu plánovače do budoucnosti. Pokud by tento limit vypršel, aniž by byl proces naplánován, bude spuštěn okamžitě. To by mělo omezit maximální latenci nových vláken.

Tento patch je ale velký a složitý a Peter varoval, že s testováním skončil, když se kód podařilo přeložit. Není to tedy něco, co by bylo možné očekávat do 2.6.36; pokud ale přežije benchmarky, možná ho uvidíme v příštím vývojovém cyklu.

Dynamické omezování zpětného zápisu

napsal Jonathan Corbet, 15. září 2010

Zpětný zápis [writeback] je proces, při kterém se nečisté [dirty] stránky v paměti (tj. ty, které byly modifikovány aplikacemi), zapíší zpět na trvalé úložiště; tím se uloží data a stránky jsou potenciálně volné pro jiné použití. Výkonnost systému značně závisí na tom, že zpětný zápis bude fungovat dobře; špatný zpětný zápis může vést k mizerné rychlosti I/O a extrémnímu tlaku na paměť. Za poslední rok je čím dál tím více jasné, že Linux zpětný zápis nedělá tak dobře, jak by měl; několik vývojářů tedy tráví čas snahou o zlepšení situace. Patch pro dynamické limity přiškrcování nečistých stránek [dynamic dirty throttling limits patch], jehož autorem je Wu Fengguang, demonstruje nový, relativně komplexní přístup ke zlepšení zpětného zápisu.

Jedním z klíčových konceptů zpětného zápisu je, že procesy, které k problému nejvíce přispívají, by také měly nejvíce trpět. V jádře je to zajištěno voláním balance_dirty_pages(), která má omezit znečišťující chování procesu, dokud se situace nezlepší. Toto přiškrcování probíhá přímočaře: Proces dostane lopatu a řekne se mu „kopej!“ Jinými slovy proces, který byl vhozen do balance_dirty_pages(), dostane za úkol najít nečisté stránky a zajistit jejich zápis na disk. Jakmile je pročištěn dostatečný počet stránek, procesu je dovoleno vrátit se zpět k jeho důležitému úkolu znečišťovat další.

Pročišťování stránek tímto způsobem má nějaké problémy, mnoho z nich bylo popsáno jinde. Jedním z nejvýznamnějších je ale to, že vytváří I/O provoz se značným pohybem hlaviček disku. Když se zpětný zápis řeší normálně na pozadí, jádro se snaží naráz vyčistit hodně stránek stejného souboru. Vzhledem k tomu, že se souborové systémy hodně snaží umístit bloky souboru na jedno místo, zápis všech stránek daného souboru by měl vyžadovat jenom omezený pohyb hlaviček disku, čímž se propustnost I/O zlepší. Jakmile ale začne pracovat balance_dirty_pages(), musí se bloková vrstva najednou potýkat se zpětným zápisem z několika zdrojů. Takže když je systém pod tlakem způsobeným nedostatkem paměti a hodně potřebuje optimální výkon blokových zařízení, přejde do režimu, kde je výkonnost horší.

Patch o sedmnácti částech provádí mnoho změn počínaje tím, že se z balance_dirty_pages() odstraňuje veškerý přímý zpětný zápis. Místo toho se proces, který může za problémy, s klidem na chvíli uspí a zpětný zápis řeší jiné části systému. To by mělo vést k vyšší výkonnosti I/O a také k předvídatelnějším a lépe nastavitelným pauzám aplikací, které intenzivně pracují s pamětí.

Větší část této série patchů se věnuje zlepšení výpočtu délky pauzy. Přidává nový mechanismus pro odhad propustnosti každého zařízení, což je něco, co v jádře v současnosti chybí. Tyto informace jsou zkombinovány s počtem stránek, které by jádro chtělo zapsat předtím, než se procesu dovolí pokračovat, a je z nich vypočítána délka pauzy. Ta nesmí překročit 200 ms.

Sada patchů se ale snaží být ještě chytřejší. 200 ms je dlouhá doba pro proces, který se snaží odvést nějakou práci. Na druhou stranu je při neopatrnosti také možné pozastavit procesy na velmi krátkou dobu, což je špatné pro propustnost. V této sadě patchů bylo rozhodnuto, že optimální pauzy trvají mezi 10 a 200 ms – tohoto rozsahu je dosaženo limitem nr_dirtied_pause specifickým pro proces. Jestliže je počet stránek zašpiněných procesem pod limitem, není vynucena žádná pauza. Když balance_dirty_pages() výpočtem dospěje k pauze kratší než 10 ms, limit je zvýšen; pokud naopak pauza překročí 100 ms, limit se sníží na polovinu. Požadovaným výsledkem ja pauza ve stanoveném rozsahu, která se rychle vrátí k 10 ms, když tlak na paměť přestane.

Další změna provedená touto sérií patchů se snaží přijít s globálním odhadem toho, kdy je systém pod tlakem kvůli nedostatku paměti. Když normální prohledávání paměti narazí na nečisté stránky, odhad tlaku je zvýšen. Pokud se naopak proces kswapd na nejvytíženějším uzlu v systému uspí, odhad je snížen. Tento odhad se používá k nastavení omezení pro procesy; když je systém pod velkým tlakem, procesy špinící paměť jsou zpomaleny dříve.

Sada patchů provádí ještě jednu významnou změnu. Vývojáři souborových systémů si již nějakou dobu stěžují, že jim vnitřní kód pro správu paměti předává ke zpětnému zápisu příliš malé množství paměti naráz. Na rychlém zařízení příliš malé požadavky na zpětný zápis zařízení nevytíží, což vede k suboptimální výkonnosti. Některé souborové systémy (xfs a ext4) dokonce požadované množství stránek pro zpětný zápis ignorují; zapíší jich mnohem více, než bylo požadováno. To může výkonnost zvýšit, ale není to bezproblémové; konkrétně vysílání masivních zápisových operací na pomalé zařízení může systém zbrzdit na neakceptovatelně dlouhou dobu.

S touto sadou patchů je zde lepší způsob, jak vypočítat nejlepší velikost pro zpětný zápis. Systém nyní ví, jak velkou propustnost může od každého zařízení očekávat; s těmito informacemi může nastavit velikost požadavků tak, aby zařízení mělo co na práci po jednu sekundu. Limity pro omezování jsou také založeny na této jednosekundové hodnotě; jestliže v systému není dost nečistých stránek pro sekundu I/O aktivity, pravděpodobně není využívána plná kapacita úložného zařízení a počet nečistých stránek může vzrůst. Ve shrnutí: Odhad propustnosti umožňuje jádru škálovat limity pro nečisté stránky a velikosti I/O požadavků tak, aby se všechna zařízení využívala co nejlépe bez ohledu na výkonnostní charakteristiky specifického zařízení.

Začlenit tento kód do hlavní řady může nějakou dobu trvat. Jedná se o komplikovanou sadu změn vnitřního kódu, který je již teď složitý; za takových okolností bude pro ostatní obtížné ho revidovat. Ohledně specifik některých heuristik byly k slyšení námitky. Také bude potřeba rozsáhlé testování výkonnosti, než bude taková změna začleněna. Budeme si tedy ještě chvíli muset počkat, ale lepší zpětný zápis by nakonec měl přijít.

Rychlé zasílání zpráv mezi procesy

napsal Jonathan Corbet, 15. září 2010

Jak počet jader v systému roste, bude také zapotřebí rychlejší komunikace mezi procesy. Tento týden jsme mohli vidět zaslání páru patchů, jejichž cílem je zrychlit zasílání zpráv mezi procesy na Linuxu; oba mají potenciál významně zlepšit výkonnost systému.

První z těchto patchů je motivován snahou zrychlit MPI. Komunikace mezi MPI uzly se v současnosti řeší pomocí sdílené paměti, ale to pro některé uživatele stále není dost rychlé. Místo kopírování zpráv do sdíleného segmentu by raději zprávy doručovali přímo do adresového prostoru jiného procesu. Za tímto účelem Christopher Yeoh zaslal patch implementující křížové připojení paměti [cross memory attach].

Patch implementuje pár nových systémových volání:

int copy_from_process(pid_t pid, unsigned long addr, unsigned long len,
                      char *buffer, int flags);
int copy_to_process(pid_t pid, unsigned long addr, unsigned long len,
                    char *buffer, int flags);

Volání copy_from_process() se pokusí zkopírovat len bytů počínaje adresou addr z adresového prostoru procesu identifikovaného pid do daného bufferu. Současná implementace parametr flags [příznaky] nepoužívá. Jak by se dalo očekávat, copy_to_process() zapíše data do adresového prostoru cílového procesu. Oba procesy musí buď mít stejného vlastníka, nebo kopírující proces kvalifikaci CAP_SYS_PTRACE; jinak nebude kopírování umožněno.

Patch obsahuje výsledky benchmarků ukazující významné zlepšení v mnoha různých testech. Reakce na koncept byla pozitivní, i když bylo poukázáno na některé problémy. Ingo Molnár naznačil, že rozhraní založené na iovec (jako readv() a writev) by možná bylo lepší; také navrhl pojmenovat nová systémová volání sys_process_vm_read() a sys_process_vm_write(). Proti tomu nikdo nebyl, takže možná v některém budoucím jádře tato volání uvidíme.

Mnoho z nás MPI na svých systémech neprovozuje, ale D-Bus se již objevuje mnohem častěji. D-Bus nebyl navržen pro výkonnost tak jako MPI, takže jeho fungování na jediném systému je o něco pomalejší. Je zde centrální démon, který směruje zprávy, takže zpráva od jednoho procesu druhému musí dvakrát projít jádrem; také je nutné probudit démona uprostřed. Z pohledu výkonnosti to není ideální.

Alban Crequy popsal možnou alternativu: Převést práci D-Busu do jádra. Za tímto účelem nový jaderný modul „kdbus“ zavádí nový typ socketu AF_DBUS. Tyto sockety se chovají podobně jako AF_UNIX, ale jádro odposlouchává veškerý provoz a zjišťuje jména spojená se všemi procesy na „sběrnici“; jakmile je tato informace zaznamenána, může jádro doručit většinu zpráv bez spolupráce démona (který ale stále existuje, aby řešil věci, se kterými jádro pracovat neumí).

Když je démon takto přeskočen, je možné doručovat zprávy s pouze jedním průchodem jádrem a jedním kopírováním. Opět bylo naměřeno významné zlepšení výkonu, i když větší zprávy stále prochází přes démona. Lidé si příležitostně na výkonnost stěžují již léta, takže by možná mělo cenu systém zlepšit tímto způsobem.

Může nicméně ještě chvíli trvat, než tento kód skončí na našich desktopech. Patche jsou k dispozici v gitovém stromě, ale nikdy nebyly pročištěny a zaslány k revizím do konference. Sada patchů není malá, takže je dost možné, že bude potřeba opravit hodně věcí, než bude možné hodnotit její možné začlenění do hlavní řady. Démon D-Bus bude podle všeho ještě chvíli mít dost práce.

       

Komentáře

[miki.lbc]

Tak tyhle jaderný noviny se mi líbí. Konečně jedny, který celý chápu. Tyhle témata se asi týkaj všech.

[kralyk z abclinuxu]

D-Bus nebyl navržen pro výkonnost tak jako MPI ...

Ano, to jsme si všimli

[stativ]

D-Bus v jádře? Jen to ne…

[Dusan]

Zníži to bezpečnosť? Prípadne pravdepodobnosť chýb? Prípadne zamŕzanie kernelu z externého zdroja? Zníži to výkon? Predĺži čas vývoja a opravy chýb? Prosím popíš prečo si myslíš, že je to zlé.

[Petr Tomášek]

Proc?

[Martin Mareš]

Právě že default je "D-bus v jádru není", takže by především měli dodat nějaký dostatečně pádný argument ti, kdož by tam jeho podporu rádi viděli.

Takovým argumentem by mohl být například benchmark, který by ukazoval, že reálné (a rozumně naprogramované) aplikace tráví v D-busu nezanedbatelné množství času.

Zkrátka k tomu, aby se do jádra přesouvalo něco, co lze vyřešit v uživatelském prostoru, by měly být setsakramentsky pádné důvody.

[trekker.dk]

takže by především měli dodat nějaký dostatečně pádný argument ti, kdož by tam jeho podporu rádi viděli.

Zvýšení výkonu dbusu (meziprocesového zasílání zpráv) s minimálním dopadem na zbytek jádra pro ty, kteří to v konfiguraci vypnou.

Zkrátka k tomu, aby se do jádra přesouvalo něco, co lze vyřešit v uživatelském prostoru, by měly být setsakramentsky pádné důvody.

V takovém případě by se z jádra měla odstranit třeba podpora pro sdílenou paměť. Lze ji vyřešit v uživatelském prostoru zapisováním sdílených dat do souboru.

[Jindřich Makovička]

Zvýšení výkonu dbusu (meziprocesového zasílání zpráv) s minimálním dopadem na zbytek jádra pro ty, kteří to v konfiguraci vypnou.

Jenže to zvýšení výkonu mi nepřišlo zas tak zásadní. Navíc, když už někdo chce tlačit skrz DBUS tisíce transakcí za sekundu, stálo by za to zamyslet se spíš nad tím, jestli je potřeba ty zprávy procesům posílat po jedné. Třeba u hlášení stavu IM kontaktů by agregace rozhodně pomohla.

[Martin Mareš]

Naprosto cokoliv lze zrychlit přesunem do jádra, ale to neznamená, že dává smysl tam postupně přestěhovat úplně celý user space.

Naopak přesun do jádra dává smysl jen tehdy, když:

(1) ukáže se, že implementace uvnitř jádra je výrazně rychlejší než v uživatelském prostoru a

(2) na té rychlosti opravdu záleží. Sdílení dat mezi paralelně běžícími procesy je často časově kritické a spousta programů tím (smysluplně) tráví 50 a více % času. Naproti tomu komunikace po D-busu je záležitostí spíše okrajovou, která se na celkovém výkonu aplikací nemá jak projevit.

[kralyk z abclinuxu]

Naprosto cokoliv lze zrychlit přesunem do jádra, ale to neznamená, že dává smysl tam postupně přestěhovat úplně celý user space.

Určitě souhlasím, nicméně rychlé IPC by tam být mohlo, ne?

[Martin Mareš]

UNIX-domain sockety? Netlink? Sdílená paměť? Co chybí?

[Vskutečnosti Saýc]

Posilani zprav.

[Martin Mareš]

Zprávu můžete triviálně poslat přes socket, co chcete víc?

[Vskutečnosti Saýc]

Abych mohl posilat zpravy mezi N procesy, budu potrebovat N socketu a drzet si nejakou mapu toho, ktery socket kam vede. To bych za trivialni neprohlasil.

[Martin Mareš]

A nestačí, aby měl každý proces jeden socket a používal sendto()?

[Vskutečnosti Saýc]

Jiste ze to staci. Ale mit mechanismus pro predavani by bylo rychlejsi a pohodlnejsi.

Koneckoncu, kdyby to nebylo potreba, nebude Dbus nacpany v kazde aplikaci. Jiste ze pokud aplikace kterou delam zavisi na rychlem rpedavani zprav, muzu ji proste napsat v erlangu a bude, ale to porad neznamena, ze by to nebylo fajn.

[Martin Mareš]

Ale mit mechanismus pro predavani by bylo rychlejsi a pohodlnejsi.

Ale sendmsg() je mechanismus pro předávání zpráv.

Koneckoncu, kdyby to nebylo potreba, nebude Dbus nacpany v kazde aplikaci.

Z více než 2500 balíčků, které mám na své pracovní stanici nainstalované, potřebuje D-bus sotva několik desítek. Takže tvrzení o tom, že je nacpaný v každé aplikaci, bych bral se značnou rezervou

D-bus je zkrátka jen jeden z mnoha používaných mechanismů na předávání zpráv a není ničím výjimečný. Ani nikdo neukázal, že by byl v nějakém smysluplném případě kritický pro rychlost. Takže je naprostý nesmysl ho přesouvat do jádra.

(Tím neříkám, že by si současná implementace D-busu nezasloužila přepsat. Použití XML pro konfigurační soubory ukazuje absolutní absenci citu pro návrh softwaru. A pokud se ukáže, že by se hodilo, aby se kernelové komunikační mechanismy (třeba netlink) naučily nějaké nové featurky, které D-busu pomohou, proč ne. Ale jádro má zůstat obecné, nikoliv šité na míru jednomu konkrétnímu módnímu výstřelku.)

[miso]

balicek != aplikace

[Martin Mareš]

Klidně číslo vydělte dvěma nebo třema (pak bude odpovídat počtu aplikací), řádově se nic nezmění.

[kralyk z abclinuxu]

Použití XML pro konfigurační soubory ukazuje absolutní absenci citu pro návrh softwaru.

Vždycky když se lidé podobně otírají o nasazení XML na nějakém místě, ptám se jich, co by bylo na tom místě lepší. Takže jaký formát bys pro konfiguraci D-Busu použil spíš a proč?
Měl bys například výhrady také proti JSONu?

(disclaimer: XML nemám nijak extra v lásce. Ale nelíbí se mi, když mnoho lidí kritizuje XML protože ho krizizuje mnoho lidí)

[pavlix]

Zkusím nastřelit aspoň svůj názor, když MJ ještě neodpověděl...

Konfiguraci v XML považuju za zlo (ale toleruju, pokud daná věc jinak plní svůj účel).

Konfiguraci v JSONu trochu používám pro své vlastní věci. Je to o dvě třídy lepší pro tenhle účel než XML. Je to obecné a funguje to... teda nouzově.

Na druhou stranu, nepovažuju JSON za ideální konfigurační formát, spíš dávám přednost formátům se složenýma závorkama, středníkama a klíčovýma slovama, prostě nějakou variantou takového toho c-like formátu.

Je stručnější než JSON (který je stručnější než XML), což je u konfigurace klíčová vlastnost, čím míň omáčky, tím líp...

A jedna klíčová věc... JSON je sice obecný datový formát s podporou polí a key-value slovníků, ale pokud vím tak neumí komentáře. Smysluplný konfigurační jazyk komentáře umět prostě *musí*.

Pak mě napadá ještě jedna... a to je hlášení chyb při parsování. Běžné parsery JSONu jednak parsují celý strom a ten předávají aplikaci, což by se dalo napravit nějakým SAX-like parserem... ale hlavně... aplikace nezná čísla řádků! Tudíž pokud parsování proběhe v pořádku, ale je tam nějaká konfigurační chyba, kterou aplikace detekuje, tak nemá možnost odkázat administrátora na konkrétní řádek, kde byla chyba detekována.

[kralyk z abclinuxu]

spíš dávám přednost formátům se složenýma závorkama, středníkama a klíčovýma slovama, prostě nějakou variantou takového toho c-like formátu.

Souhlasím, že tenhle formát je dobrý, problém je, že (AFAIK) bohužel neexsituje jednotný standard, a tak si to každá aplikace implementuje jinak... což je problém.

A jedna klíčová věc... JSON je sice obecný datový formát s podporou polí a key-value slovníků, ale pokud vím tak neumí komentáře. Smysluplný konfigurační jazyk komentáře umět prostě *musí*.

Hm, jo no, to je u JSONu problém. Některé parsery nicméně komentáře neoficiálně podporují, jako např. jsoncpp, který trochu znám. Ve standardu to ale už není, bohužel.

ale hlavně... aplikace nezná čísla řádků!

Hm, tohle bude spíš záležitost parseru, než formátu jako takového, ne?

[pavlix]

a tak si to každá aplikace implementuje jinak... což je problém.

Zas tak velký problém to není. Trochu to komplikuje tvorbu specializovaných editorů těch konfiguračních souborů (různých grafických nebo web rozhraní apod).

Hm, jo no, to je u JSONu problém. Některé parsery nicméně komentáře neoficiálně podporují, jako např. jsoncpp, který trochu znám. Ve standardu to ale už není, bohužel.

Potom to chce se shodnout aspoň na commented JSON :).

Hm, tohle bude spíš záležitost parseru, než formátu jako takového, ne?

Teoreticky ano. Šlo by ty čísla řádků pro aplikaci ukládat. Nějaký SAX-like parser by to mohl umět, objektový parser taky, pokud to neni nějaké implicitní mapování. Ale dělá to nějaký?

[Martin Mareš]

Vždycky když se lidé podobně otírají o nasazení XML na nějakém místě, ptám se jich, co by bylo na tom místě lepší.

Obecná odpověď je, že S-expressions (alias lisp-like uzávorkované výrazy) jsou v každém případě lepší než XML, protože umějí totéž a daleko jednoduššími prostředky. Ale ačkoliv jsou lepší, od optima mají v případě konfigurace stále propastně daleko.

Použil bych formát, který je především rozumně čitelný pro lidi (věci se v něm nepíší zbytečně komplikovaně) a který umožňuje konfiguraci snadno skládat z více částí (včetně toho, že lze předefinovat cokoliv už nadefinovaného, tedy například distribuční defaulty).

Jeden takový jsme kdysi s Robertem Špalkem spáchali (viz popis) a myslím, že se osvědčil. Je to docela dobrý kompromis mezi strojovou zpracovatelností, příjemností pro lidi a flexibilitou.

[tom]

V takovém případě by se z jádra měla odstranit třeba podpora pro sdílenou paměť. Lze ji vyřešit v uživatelském prostoru zapisováním sdílených dat do souboru.

Az na to, ze presne tak je to naimplementovane. Udela se soubor v "ramdisku" v /dev/shm a ten si procesy namapuji :P

[trekker.dk]

Ok, tak třeba pro souborové systémy. Ty lze taky vyřešit v uživatelském prostoru zápisem přímo na zařízení.

[pavlix]

A jak potom bude jádro spouštět ten uživatelský prostor. Myslím tím obecné distribuční jádro, ne zkompilované na míru.

[trekker.dk]

Vím já, třeba tak, že to, co se má spustit, musí začínat na disku na adrese xyz. Podstatné je pro mě to, že to jde vyřešit a to je podle všeho jediné kritérium, které toto vlákno má.

[pavlix]

Filesystém je právě abstrakce, která slouží k tomu, aby to, co se má spustit, mohlo začínat na libovolné adrese a vyhledávalo se podle jména.

Podstatné je pro mě to, že to jde vyřešit a to je podle všeho jediné kritérium, které toto vlákno má.

Až na to, že ty jsi reagoval na Martina, který rozhodně toto za jediné kritérium neoznačil.

Dokonce ve všech třech větách toho příspěvku dává najevo úplně jiné kritérium.

[Sten]

V jádře nebude D-Bus, ale podpora D-Busu. Stačilo by si přečíst tu zprávičku

[stativ]

Samozřejmě jsem si přečetl a za svým názorem si stojím. Už teď je jádro až příliš nabubřelé a přidání další věci, která může být docela snadno implementované a user space věci rozhodně nepomůže.

A proč mi vadí nabubřelost jádra? Jádro je pak náchylnější k chybám – čím víc kódu tím víc chyb. A samozřejmě když ten kód běží v kernel space, tím nebezpečnější ty chyby můžou být.

[petr_p]

Ale chápejte, že předávání zpráv musíme do jádra dostat. Jak jinak chcete z Linuxu udělat mikrojádro?

[mimi.vx]

+1

[stativ]

Já tak nějak čekal, že už tam něco je.

[Aleš Janda]

Právě že moc není. Pokud vím, tak předávat zprávy mezi procesy se dají pomocí POSIX messages, jenže to není navázané na konkrétní proces, v podstatě se to chová jako soubor a po ukončení procesu to tam zůstane (pokud ho ten proces po sobě explicitně nesmaže). Pak je tu mkfifo, což má podobný problém, pak sdílená paměť (opět, to samé, při sestřelení to zůstane viset v paměti), anonymní mmap (to skončení procesu nepřežije, ale lze předávat jen v rámci dvou procesů, kde jeden vznikne fork()em druhého. Navíc žádný z těchto způsobů neumožňuje předat data procesu s konkrétním PID. A nakonec tu jsou signály - ty jsou ale kvůli asynchronnosti jednak příšerné řešení a jednak se dá předat samotná informace „nastal signál“, ale už se nedají předat žádná data.

Takže d-bus na úrovni jádra by byl hodně fajn.

[tom]

A nakonec tu jsou signály - ty jsou ale kvůli asynchronnosti jednak příšerné řešení a jednak se dá předat samotná informace „nastal signál“, ale už se nedají předat žádná data.

Daji se predat data minimalne o velikosti adresy. A vubec toho jde delat mnohem vic - RTFM signal(7).

Pak tu jsou jeste SYS-V zpravy a sockety.

A sdilena pamet jde udelat i tak, aby potom, co ji vsichni odmapuji, byla uvolnena.

[Martin Mareš]

Signály můžete navíc provozovat i synchronně, viz signalfd(2).

[m]

Male nedopatreni: Clanek se nezobrazuje v sekci http://www.abclinuxu.cz/clanky/jaderne-noviny

Diky za opravu a za ctivy serial