Jaderné noviny – 5. 7. 2012: Jaderné urychlení D-Busu

23. 7. 2012 | Luboš Doležel | Jaderné noviny | 3380×

Aktuální verze jádra: 3.5-rc5. Citáty týdne: Andrew Morton, Dave Chinner. Kernel Patchwork se vrací. UEFI secure boot a TianoCore. Chybějící AF_BUS.

Obsah

• Aktuální verze jádra: 3.5-rc5
• Citáty týdne: Andrew Morton, Dave Chinner
• Kernel Patchwork se vrací
• UEFI secure boot a TianoCore
• Chybějící AF_BUS

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

Aktuální vývojová verze jádra je 3.5-rc5 vydaná 30. června. Linus k ní řekl: Nic, z čeho bych měl obavy, tam není. Navzdory slučování v síťování (které bylo docela velké) je -rc5 menší než -rc4, i když je tam o trochu více commitů. Takže to jde zdá se správným směrem.

Stabilní aktualizace: za poslední týden žádné nevyšly. Verze 3.2.22 se aktuálně reviduje.

Citáty týdne: Andrew Morton, Dave Chinner

Najděte si prosím velkou pastelku a na čelo si napište „když opravuji chybu, tak vždy musím popsat dopad této chyby na uživatele“.

-- Andrew Morton

8k stacky jsou na x86-64 příliš malé při stále složitějších úložných vrstvách a hloubkách volání o více než 100 funkcích.

-- Dave Chinner

Kernel Patchwork se vrací

Administrátor Kernel.org John Hawley oznamuje, že systém patchwork konečně zase funguje. Všechny původní účty byly zachovány, ale je *DŮRAZNĚ* doporučováno si po přihlášení změnit heslo.

UEFI secure boot a TianoCore

James Bottomley sepsal své těžce nabyté znalosti, jak zprovoznit UEFI secure boot pod QEMU a o TianoCore, a dal je na webovou stránku. Pro ty, co s tímto potřebují pracovat, obsahuje spoustu informací. Intel vytvořil projekt nazvaný TianoCore, které je otevřenou implementací firmwaru UEFI. Jedním z podprojektů uvnitř TianoCore je OVMF, cože je Open Virtual Machine Firmware. A je to právě OVMF, které používáme pro vytvoření obrazu virtuálního stroje pro QEMU, který bude fungovat v prostředí UEFI secure boot. TianoCore secure boot funguje jen od verze r13466 v SVN. Tato verze ještě nebyla vydána v podobě .zipu.

Chybějící AF_BUS

D-Bus se za léta stal standardní součástí linuxového desktopu pro komunikaci mezi procesy. A stejně dlouho se už snaží vývojáři najít způsob, jak D-Bus urychlit. Posledním pokusem je patch do jádra, který přidává novou „rodinu“ soketových adres (nazvanou AF_BUS) do síťovací vrstvy. Mluví se o výrazném navýšení výkonu, ale stejně jako u předchozích pokusů bude problém to dostat do jádra.

D-Bus implementuje mechanismus, pomocí kterého si mohou procesy mezi sebou zasílat zprávy. Multicast je přirozenou vlastností protokolu; jedna zpráva může jít více adresátům. D-Bus zaručuje spolehlivé doručování, což znamená, že zprávy dorazí v pořadí, v jakém byly odeslány, a multicastové zprávy budou doručeny buď všem adresátům, nebo žádnému, pokud doručení není možné. Součástí protokolu je bezpečnostní mechanismus, pomocí kterého může být doručení omezeno na určité příjemce. Všechny tyto funkce jsou využívány současnými systémy, které očekávají robustnost, bezpečnost a pokud možno co nejnižší latenci.

Současná implementace D-Busu používá unixové sokety a centrální routovací démon. Funguje to, ale routovací démon znamená extra přepínání kontextů, režii a latenci u každé zprávy. Jádro nemůže pomoci s prioritním doručováním, takže všechny zprávy způsobují probouzení, která zpomalují zpracování důležitějších zpráv; zde najdete popis toho, jak tyto potíže mohou dolehnout na běžící systém. Už nějakou dobu bylo vývojářům jasné, že je třeba najít lepší řešení.

V tomto ohledu se už objevilo několik pokusů. Posledně šlo o sadu patchů, které přidávaly podporu multicastu do unixových soketů. Tento nápad byl zavržen s tím, že kód unixových soketů je už tak příliš komplikovaný a další zhoršování současné situace nemá dostatečné opodstatnění. Vývojářům D-Busu bylo řečeno, že mají prostě použít IPv4 sokety, kde už podpora multicastu je.

Vývojáři namísto toho implementovali AF_BUS, novou „rodinu“ adres navrženou s cílem splnit požadavky D-Busu. Poskytuje spolehlivé doručování, které D-Bus vyžaduje; navíc má schopnost předávat deskriptory souborů a ověřovací údaje [credentials] mezi procesy. Má to vestavěné zabezpečení, kód netfilteru (rozšířený o nový parser zpráv D-Busu) se používá pro rozhodování, které zprávy mají být doručeny kterým procesům. Výsledkem je údajně značné snížení režie D-Busu díky menšímu počtu systémových volání; Vincent Sanders říká, že jde o zdvojnásobení propustnosti a méně než poloviční latenci. Podrobnosti fungování najdete v souvisejícím dokumentu.

Dvojnásobné zlepšení v komponentě na Linuxu hojně využívané by jistě bylo vítáno. Tento patch ale vítán nebyl; správce síťování David Miller hned dal najevo, že má v plánu patch naprosto ignorovat. Jeho argumentem je to, že IPv4 sokety postačují a že spolehlivého doručování multicastových zpráv nelze dosáhnout, a to ani v omezeném rozsahu, jak to vyžaduje D-Bus. Vyjádřil pochybnosti, že IPv4 vůbec vyzkoušeli, a uzavřel to: Nebudeme v jádře vytvářet další rodinu adres, která bude přítomna pro jednoho jediného náročného uživatele.

Vincent odpověděl, že už toho zkusili hodně a nic nepostačovalo. IPv4 sokety nemohou poskytovat potřebné záruky doručení a neumožňují předávání deskriptorů souborů a ověřovacích údajů. Důležité je prý i to, že D-Bus musí fungovat ještě před nastavením a spuštěním síťování; nastavování IP rozhraní na současných systémech často vyžaduje komunikaci před D-Bus. Tvrdí, že lepší řešení neexistuje.

Získal si ale podporu několika jiných vývojářů, včetně Alana Coxe, který poukázal na to, že systémů s požadavky podobnými D-Busu není zrovna málo:

Pravdou je, že když se porozhlédnete, najdete spoustu multicast messaging systémů, které dělají spolehlivé doručování nad IP. Red Hat dokonce poskytuje vysokoúrovňovou clusterovou službu, která dělá právě to (stejně jako dbus na úrovni desktopu) plus hromada věcí navrch toho (JGroups apod.)

Na aplikační úrovni se tento typ služeb používá už roky (Websphere MQ, TIBCO, RTPGM, OpenPGM, MS-PGM a tak dále). Pro protokoly na bázi PGM dokonce existují akcelerátory v Cisco routerech a Solarflare toho dokáže zvládnout hodně přímo na své 10Gbit kartě.

Dodal, že latence je na současných systémech zásadní a že jedním z nejlepších způsobů, jak ji snížit, je snížit počty přepínání kontextů a procesů, kterými musí zpráva projít. Chris Friesen dodal, že jeho firma používá rodinu protokolu na bázi AF_UNIX pro multicast messaging vyvinutou mimo jádro, která by jistě mohla být nahrazena něčím jako AF_BUS, pokud by se toto dostalo do jádra.

Jiných patchů pro lokální messaging se za roky objevilo už víc. Takže je jasné, že je tu značný zájem o takovou funkčnost v Linuxu. Ale zájem jako takový není dostatečným opodstatněním pro začlenění velkého patche; musí zde být i shoda mezi vývojáři, kteří mají na starosti to, aby Linux měl dlouhodobě vysoce kvalitní síťovou vrstvu. Shodu ještě nemáme, takže ještě asi bude muset dojít ke značenému mezilidskému multicast messagingu, než budeme mít potřebnou podporu v jádře.

       

Komentáře

[Jardík]

Řešení přece existuje. Forknout linux!

[kei.101]

To spíš přejít na BSD.

[Salamek]

Ono kazda distribuce je vice mene fork vanila linuxu :)

[pavlix]

Řešení čeho?

[pavlix]

Najděte si prosím velkou pastelku a na čelo si napište „když opravuji chybu, tak vždy musím popsat dopad této chyby na uživatele“.

Zkoušel sis kreslit pastelkou po kůži?

http://en.wikipedia.org/wiki/Crayon

[Jardík]

sis?

[zxtlpn]

Mhm?

[Jardík]

Hmm... nikdy jsem to neviděl ^^.

[pavlix]

Člověk se pořád učí.

[Peter Golis]

Stačí trošku nahriať.

[aaaaaaaaaaaaaaa]

8k stacky jsou na x86-64 příliš malé při stále složitějších úložných vrstvách a hloubkách volání o více než 100 funkcích.

To myslia vazne? Ja si nedokazem udrzat "globalny pohlad" uz pri necelych 20 neprazdnych vrstvach v Jave, takze zo mna asi kernel developer nebude :-/.

[stativ]

Rekurze?

[pavlix]

Ten AF_BUS zní docela zajímavě a mohl by z toho být pěkný flame.

[BFU]

Mohl ? ...

[chrono]

Možno by celkom stačilo, aby si aplikácie cez DBUS neposielali obrovské množstvo dát (a ak už musia, tak aby radšej posielali jednu veľkú správu, ako 100 malých).

[Jardík]

Já jsem zatím nenarazil na SW, co by posílal nějaká velká data přes dbus. Zatím tak možná networkmanager, udisks(2), kdysi HAL, ... a ty všichni posílájí pár informací o které si řeknete. Potom ještě GTK aplikace používající G(tk)Application se usídlí na dbusu a ty si většinou posílají akorát argumenty do předchozí instance aplikace, aby běžela jen jednou.

[Luboš Doležel (Doli)]

No to je geniální. A jako řešení nedostatečných diskových kapacit prostě nebudeme ukládat data.

a ak už musia, tak aby radšej posielali jednu veľkú správu, ako 100 malých

Tak tě odpojíme od Internetu a na konci měsíce nám vždy dáš soupis toho, co chceš za data. Abys to měl jako jeden velký download místo X malých.

[Michal Vyskočil]

Až na to, že tohle neřeší žádný z problémů (latence, context switch, inverzní priority), které má AF_BUS řešit.

[Martin Mareš]

Přes několikeré výzvy v LKML jsem neviděl, že by proponenti AF_BUS ukázali naměřená data, ze kterých by bylo vidět, že tyto problémy doopravdy existují. Zatím jenom máchají rukama a mají plnou tlamu řečí o tom, jak moc je to potřeba, ale to v komunitě okolo jádra vážně nefunguje. Jinými slovy nejprve by měli ukázat, že AF_BUS řeší nějaké reálné problémy, nejen hypotetické.

[pavlix]

+1

A ideální by bylo, kdyby se to opravdu netýkalo jen dbusu ale i dalších obdobných systémů.

[dumblob]

A ideální by bylo, kdyby se to opravdu netýkalo jen dbusu ale i dalších obdobných systémů.

+1

[Michal Vyskočil]

Tak já o tom víc docela kulové, takže jsem napsal má řešit.

[stativ]

Dřív jsem to považoval za zbytečné bobtnání jádra, protože jsem uvažoval d-bus jenom za jakousi ptákovinu, která mi umožňuje volat nějaké funkce různých programů. Když jsem si neuvědomil, že to vlastně není nic jiného než nástroj pro meziprocesovou komunikaci, tak jsem svůj názor rychle změnil.

Něco takového mělo být v jádře už dávno. Potřeba komunikace mezi procesy je vcelku častá věc. Kvůli tomu tady spousty různých implementací běžící v userspace, a všechny mají problém s řešením latence. A za bloat se to moc považovat nedá, uvažujeme-li, že prostředky pro meziprocesovou komunikaci jsou základním kamenem mikrokernelů.

[pavlix]

Dřív jsem to považoval za zbytečné bobtnání jádra, protože jsem uvažoval d-bus jenom za jakousi ptákovinu, která mi umožňuje volat nějaké funkce různých programů. Když jsem si neuvědomil, že to vlastně není nic jiného než nástroj pro meziprocesovou komunikaci, tak jsem svůj názor rychle změnil.

+1

Stejným vývojem bude procházet množství jaderných vývojářů. Ale podle mě je dobře, že AF_BUS nechtějí, protože to vytváří tlak na revizi AF_BUS vzhledem k ostatním IPC službám. A tím, že budou vývojáři potřebovat podporu vývojářů jiných IPC, se zajistí univerzalita a kvalita této implementace.

A za bloat se to moc považovat nedá, uvažujeme-li, že prostředky pro meziprocesovou komunikaci jsou základním kamenem mikrokernelů.

D-bus je prostě do určité míry neoblíbený. Má to svoje důvody, i validní, o tom bych se mohl rozpovídat, ale to radši udělám, až budu mít v ruce nějakou možnost nápravy.

Ale v tuhle chvíli nevím o žádné smysluplné náhradě a spíš mi přijde, že by mělo smysl zapracovat na tom dbusu.

[stativ]

Stejným vývojem bude procházet množství jaderných vývojářů. Ale podle mě je dobře, že AF_BUS nechtějí, protože to vytváří tlak na revizi AF_BUS vzhledem k ostatním IPC službám. A tím, že budou vývojáři potřebovat podporu vývojářů jiných IPC, se zajistí univerzalita a kvalita této implementace.

Rozhodně souhlasím. Krom toho, špatně navržené API je skoro horší než žádné, protože takového API se člověk těžko zbaví.

[dumblob]

+1

[little.owl]

+1

[Ladicek]

Proto třeba Android má vlastní IPC v jádře (Binder) od samého začátku.

[Ondrej 'SanTiago' Zajicek]

Jedna vec je ze by se hodila nejaka rozumna lokalni meziprocesorova komunikace, druha vec je, zda ty detaily, ktere ma dany navrh AF_BUS, jsou rozumne. Me napadaji hned dve pripominky:

1) Je otazka, zda zavadet novou AF, kdyz mame AF_UNIX pro streamove IPC, mozna by plne stacilo ji rozsirit o (unicastovou a multicastovou) datagramovou komunikaci.

2) Pristup AF_BUS k reliable multicastum (pokud nejaky prijemce nema misto v prijimacim bufferu, selze send) je IMHO dost podivny. IMHO je daleko rozumnejsi se na reliable multicasty vykaslat, zavest pouze ordered multicasty (se zajistenim usporadani mezi unicasty a multicasty na stejnem socketu) s tim, ze pri 'vypadku' se nahodi flag a receiver se o nem tedy dozvi.

[stativ]

AF_DBUS jsem nestudoval, ale je fakt, že dobré API se musí pořádně upéct. Chtělo by to, aby se do diskuse zapojilo co nejvíce více lidí, včetně vývojářů jiných IPC řešení. Hodně by mohli pomoci lidi stojící za zmiňovaným Binderem v Androidu.

[pavlix]

AF_BUS

[Michal Vyskočil]

1) Je otazka, zda zavadet novou AF, kdyz mame AF_UNIX pro streamove IPC, mozna by plne stacilo ji rozsirit o (unicastovou a multicastovou) datagramovou komunikaci.

Pokud si pamatuji, tak AF_UNIX byl zavržen správci jádra kvůli příliš komplexnímu kódu.

2) Pristup AF_BUS k reliable multicastum (pokud nejaky prijemce nema misto v prijimacim bufferu, selze send) je IMHO dost podivny. IMHO je daleko rozumnejsi se na reliable multicasty vykaslat, zavest pouze ordered multicasty (se zajistenim usporadani mezi unicasty a multicasty na stejnem socketu) s tim, ze pri 'vypadku' se nahodi flag a receiver se o nem tedy dozvi.

Souhlasím - kdo by chtěl systém, jehož IPC je možné tak triviálně zablokovat.

[Martin Mareš]

Pokud si pamatuji, tak AF_UNIX byl zavržen správci jádra kvůli příliš komplexnímu kódu.

No právě – a teď se ty nejsložitější věci (jako předávání file-descriptorů) kopírují i do AF_BUS :(

DBUS přeci nepotřebuje tak často předávat FD, aby to nešlo vyřešit pomocným socketem v AF_UNIX.

[kralyk z abclinuxu]

Něco takového mělo být v jádře už dávno. Potřeba komunikace mezi procesy je vcelku častá věc.

Ano, ale v jádře to dost dobře nemůže být tímhle způsobem...

Ta nutnost bežícího démona je imho nějvětší nevýhoda D-Busu. Mnohem lepší by bylo, aby jádro poskytovalo dostatek použitelných IPC primitiv a nad nimi se může postavit userspace implmentace, třeba kniovna, pomocí které by aplikace komunikovaly P2P bez nutnosti centrálního bodu (mimo jádro, samozřejmě).

Je dokonce otázka, jak moc na tohle současná IPC/synchronizační primitiva poskytovaná Linuxovým jádrem stačí / nestačí. Imho by klidně mohla. Viz např. jak to řeší Chromium. Neříkám, že to má řešeno ideálně, jen se mi ta filosofie zamlouvá mnohem víc než D-Bus. Je to taky lepší z hlediska multiplatformnosti - D-Bus zrovna dvakrát přenositelný není.

[petr_p]

Linux má velké množství IPC primitiv. Bohužel žádné nesplňuje všechny požadavky. A cetrální bod je třeba – někdo musí garantovat identitu komunikujících stran a zajistit synchronizaci. Nebo chceš, aby přehrávač hudby hlasoval, jestli upowerd smí zavolat halt(2)?

[kralyk z abclinuxu]

A cetrální bod je třeba – někdo musí garantovat identitu komunikujících stran a zajistit synchronizaci.

To mi nepřijde dostatečné odůvodnění. Na to, aby mi přehrávač nesmazal systém, taky nepotřebuju démona, kterej to bude hlídat.

[Ondrej 'SanTiago' Zajicek]

Vyhoda lokalnich IPC primitiv je ta, ze autentizaci muze zajistit kernel. Treba u unix socketu se proste ridi beznymi pristupovymi pravy onoho socketu.

Zda je treba centralni dbus daemon - no nevim, bezny a leta overeny pristup je ten, ze kdo poskytuje nejakou sluzbu, ten si proste vytvori vlastni unix socket, a kdo ji chce vyuzit, tak ten socket proste otevre a preda pozadavek.

[kralyk z abclinuxu]

bezny a leta overeny pristup je ten, ze kdo poskytuje nejakou sluzbu, ten si proste vytvori vlastni unix socket, a kdo ji chce vyuzit, tak ten socket proste otevre a preda pozadavek.

Jasný, při client-server architektuře to celkem není problém. Horší je, když potřebuješ komunikovat mezi N aplikacemi, z nichž žádná není server a u žádné není známo, jestli bude ukončena dříve nebo později než kterákoli jiná.

Jako příklad viz Oxygen (Qt Styl). Ve chvíli, kdy v nastavení systému změníš barevné schéma (nebo prostě nějaký nastavení Oxygenu), tak ta aplikace, která to nastavení změnila, pošle po D-Busu zprávu všem ostatním Qt aplikacím, že si mají nastavení aktualizovat a projevit změny navenek.

Jak by se tohle řešilo bez centrálního bodu? Napadá mě akorát nějaká kombinace signálů a shmem, ale fakt nevim, jestli by to takhle šlo udělat použitelně a efektivně...

[Ivan]

Kdysi jsem na jednom sytemu zalozenem na zpravach delal. Na prvni pohled to bylo hezky a rychle se v tom vyvijelo. Vsechno bylo pekne izolovany. Kdyz ale nastaly nejaky problemy tak se to neskutecne blbe ladilo. I kdyz mate core dump, tak stejne nezjistite kdo komu poslal jakou zpravu a v hlavne v jakym poradi. Taky nebylo uplne jednoduchy dodrzet jednotny format zprav napric celym systemem.

Suma sumarum mi prijde, ze D-Bus je vylozene desktopova zalozitost. Uz treba jen to spousteni sluzeb podle potreby - kdo to potrebuje? Kdysi se Woknam vycitalo, ze se z desktopovyho systemu dela server. Linux jde dneska stejnou cestou. Veci, ktery puvodne vznikly pro desktop pomalu musi bezet i na serveru.

Pritom na je na posilani zprav zalozen i kazdy cluterware sw. Podivejte se jak funguje treba Veritas anebo Oracle RAC(evms).

[kralyk z abclinuxu]

Kdysi jsem na jednom sytemu zalozenem na zpravach delal. Na prvni pohled to bylo hezky a rychle se v tom vyvijelo. Vsechno bylo pekne izolovany. Kdyz ale nastaly nejaky problemy tak se to neskutecne blbe ladilo. I kdyz mate core dump, tak stejne nezjistite kdo komu poslal jakou zpravu a v hlavne v jakym poradi. Taky nebylo uplne jednoduchy dodrzet jednotny format zprav napric celym systemem.

Souhlasim, taky bych do toho radši nešel, ne tam, kde se dá použít jiný mechanismus. Komplexnost D-Busu se mi vůbec nelíbí. Ale někdy prostě nějaké to IPC potřebuješ.

Uz treba jen to spousteni sluzeb podle potreby - kdo to potrebuje?

Třeba já

[Josef Kufner]

DBus také umí služby spouštět až když jsou potřeba. To jde s unixovými sockety docela těžko a je to jeden z hlavních důvodů, proč je centrální démon potřeba.

[petr_p]

A co je Linux, který řeší přístupová práva k socketům? To není centrální démon? Nezapomeň, že unixové sockety nejsou jen o otevření socketu, ale také o zasílání ověřené totožnosti (SCM_CREDENTIALS), což je věc kterou s jiným socketem nebo mimo jádro neuděláš (zůstaňme na úrovni socketu; samozřejmě že je možné vytvořit autentizační mechanismus na vyšší úrovni).