Greg Kroah-Hartman pracuje na AF_BUS

Greg Kroah-Hartman pracuje na podpoře AF_BUS v jádře, o které se už psalo v Jaderných novinách. Existence AF_BUS by urychlila používání D-Busu. Protože je ale původní implementace pro jaderné vývojáře nepřijatelná, Greg tedy plánuje vývoj nové. Výsledkem by mělo být nahrazení libdbus jinou knihovnou se stejným API, která ale bude směrovat zprávy přes jádro místo přes démona dbus.

11.2.2013 13:23 | Luboš Doležel (Doli) | Zajímavý software

Komentáře

[blami]

Konecne se DBUS dostane tam kam ve skutecnosti patri. (nothing blocks)

[chrono]

Snáď bude tentoraz vyriešený aj prípad, keď budú správy smerovať viacerým programom a jeden program ich prestane preberať. (a ak si dobre spomínam, v pôvodnej implementácii bolo podobných problémov niekoľko)

[little.owl]

AF_BUS byl odmitnut a tohle by melo byt neco jineho, puvodni implementace by ale mela snad zustat nejakou dobu jak je.

This includes the crazy automotive Linux developers, who try to shove tens of thousands of D-Bus messages through their system at boot time, all while using extremely underpowered processors.

Citim se urazen ...

[Rezza]

A opravdu nekdo neco takoveho dela?

[little.owl]

Trochu prehani, ale ten pozadavek na rychle IPC v ramci kernelu tu je.

Mel jsem moznost videt kod, kde byla snaha po startu systemu protlacit pres dbus cca 400 zprav, vesmes ruznych konfiguracnich parametru, tak jak byly nacteny host procesorem z EEPROM a jak chodily updaty z jinych ECU. Slepa ulicka, pomale a blokujete to, muselo se to delat jinak a proto je tlak na AF_BUS.

Pro nektere kernel vyvojare divajici se na svet perspektivou desktopoveho CPU jsou i 800Mhz ARM A8 s 256MB pameti underpowered a bohuzel jedna vec ktera se u automotive absolutne neda uhrat je boot time. Pokud se nevejdete do limitu, kontrakt konci a obvykle se to tak nejak zjisti az ke konci projektu, pak je to krvavy boj o kazdou milisekundu.

[dustin]

A tak je to správně. Podle mě tlak ze strany prostředí, kde na věcech opravdu záleží, může kernelu jenom prospět.

[Ivan]

A jsou opravdu zpravy tim spravnym resenim? Cim vic pouzivam gnome tak se mo zda, (a je to smutny), ze wokna proste fungujou lip. Staci abych "omylem" spustil neco co donuti kernel swapowat. Linux swapuje rad a neni potreba ho moc nutit. Dokud se nepouzival DBUS tak to moc nevadilo, uzivatel pracoval pouze s jednou aplikaci a na Xka ma memory management nejaky "hack". S DBUSem je to ale horsi, kvuli kdejaky kravine musi kernel "ativovat" bambilion procesu to to proste trva dlouho.

Mozna by pomohlo, kdyby dbus pouzival mlockall, jako to delaji clusterware demoni.

[JoHnY2]

Tak on NT kernel a pridruzenej balast je message based kam se clovek podiva. Je to jeden z duvodu proc je podle me NT kernej asi nejzdarilejsi pocin MS.

Narozdil od napriklad Exchange serveru, kterej vzdycky byl rozpadajici se chaos a bordel podivne svazanejch komponent (hity jako ze vam spadne kvuli bugu Exchange a IIS (web server). Protoze se ve Win 2008 pouziva IIS i pro beh konfiguracniho klikatka pro exchange, tak bohuzel nemuzete nastaveni opravit. Konfigurace je ulozena cert vi kde a sluzby pri nahozeni opet spadnou. Konci to pak opravou ze spesl terminalu ... je specialne debilni ).

[little.owl]

Tak obvykle poslanim message pres D-Bus nestartujete LibreOffice, Gnome3 pouzivam a ze by tohle byl zrovna problem se mi nezda.

Jinak k posilani zprav - je to jedna z cest jak designovat aplikaci a v RTOS systemech celkem pouzivana pro ne RT udalosti. Nebezpeci je spise v tom, ze se to nespravne uchopi - A posle zpravu B, B ji lehce upravi a posle C a D .. pak vam tam litaji zpravy jak vztekle a diky jejich cachovani a frontam nevite v jakem stavu system vlastne je. Pokud to uchopite dobre, problem zacnou byt treba latencies ci locking a tohle by castecne presunuti podpory do kernelu mohlo situaci resit.

[Ivan]

Samotne poslani zpravy asi neni problem. Pokud ale cekam na odpoved a prijemce je zrovna ve swapu tak to muze trvat dlouho. Napr. (alespon myslim ze to tak je) kliknu v horni liste na "hodiny", aktivuje se evolution-data-server aby se mi zobrazil kalendar. Pokud ale mam nakofigurovane pripojeni k Exchange a nemam vytocenou VPNku, tak mi desktop vytuhne na 15 minut.

Kernel dava "prioritu" procesum, ktere maji otevreny ridici terminal, u tech se predpoklada, ze uzivatel vyzaduje rychlou odezvu. Procesy jako gconfd maji "smulu".

[little.owl]

Pokud ale mam nakofigurovane pripojeni k Exchange a nemam vytocenou VPNku, tak mi desktop vytuhne na 15 minut.

To je na rozlobeny bug report.

[David Jaša]

Ano. Zrovna v evolution a e-d-s je podobných radostí povícero.

[little.owl]

Hezke, jeste ze Evolution nepouzivam ... to je hodne podobne tomu, co popsal Ivan.

[David Jaša]

Pokud ale mam nakofigurovane pripojeni k Exchange a nemam vytocenou VPNku, tak mi desktop vytuhne na 15 minut.

Tohle není chyba kernelu, ale buď desktopu (který se synchronně ptá e-d-s na něco, co může trvat dlouho, třeba celý TCP timeout), nebo samotného e-d-s (v bleděmodrém to samé, akorát o jeden krok dál).

[Ivan]

Jo jasne kernel za to nemuze. Ale i kdyby e-d-s fungoval vyborne, tak stejne bude nejakou dobu trvat nez ho kernel vytahne ze swapu. Nedavno se mi pri debugovani stalo, ze jsem omylem zmacknul 2x TAB pri vytvareni breakpointu. GDB zacalo generovat kombinace vsech moznych symbolu a komletne zahlusilo celej pocitac. A neslo s tim nic udelat. Kdyz jeste mel 32MB Ram a pracoval jsem v konzoli tak nebyl problem zabit takovy proces. V gnome-terminalu uz to tak snadno udelat nejde. Jakmile se nejaka gnome "komponenta" dostane do swapu, tak cele gui prestane reagovat.

To i v tech woknach muzu spustit task managera "za kazde situace".

Proste mi prijde, ze kernel rad haze "nepouzivane" procesy do swapu a pritom nechape, ze bez nich ostatni procesy nemuzou fungovat. Ja bych se klidne smiril s tim, ze mi bude kompilace trvat o par vterin dyl, jen kdyz budu moct behem kompilace delat i neco jinyho.

[chrono]

To má kernel zisťovať, či bolo spustené gcc a podľa toho prispôsobovať swapovanie?

[Ivan]

On uz to dela, akorat soucasny desktop - zalozeny na posilani zprav - s tim neni uplne kompatibilni. Procesy ktere maji "terminal" (/dev/ttyx, /dev/pts/x) jsou "interaktivni" a predpoklada se u nich, ze vyzaduji mensi latenci. Proto se nadavaji do swapu tak casto. Na druhou stranu kernel "penalizuje" procesy, ktere se "zblazni" a generuji prilis mnoho sycallu - do toho spadaji i procesy ktere posilaji zpravy.

[chrono]

Naozaj to tak kernel robí, alebo to bola len jedna z možností, ako vylepšiť latecniu pomocou zaraďovania procesov do cgroups? (a kde sa nakoniec na rozhodovanie použilo niečo iné a nie to, či proces používa terminál)

[little.owl]

To i v tech woknach muzu spustit task managera "za kazde situace".

Windows na tom nejsou moc lepe. Prave ted to mohu pozorovat v primem prenosu - kompilace a pokus spustit Lotus Notes a system je mrtev.

Ja bych se klidne smiril s tim, ze mi bude kompilace trvat o par vterin dyl, jen kdyz budu moct behem kompilace delat i neco jinyho.

Treba cgroups a cgexec.

[Matlák]

To i v tech woknach muzu spustit task managera "za kazde situace".

Však jo, ctrl+alt+f1, killall.. než hejbat myší, z toho bolí ruce.

[luky]

Trochu prehani, ale ten pozadavek na rychle IPC v ramci kernelu tu je.

Mel jsem moznost videt kod, kde byla snaha po startu systemu protlacit pres dbus cca 400 zprav, vesmes ruznych konfiguracnich parametru, tak jak byly nacteny host procesorem z EEPROM a jak chodily updaty z jinych ECU. Slepa ulicka, pomale a blokujete to, muselo se to delat jinak a proto je tlak na AF_BUS.

Neslo by to poslat pres netlink?

[little.owl]

Slo, ale nekdy i to je pomale; pomale zde znamena overhead a latence. Staci se kouknout na CMA.

[Rezza]

Jeste i mimo automotive by se to mohlo dostat - ted jsem videl bootovani infotainmentu (cekam, ze se v autech na linuxu resi jen tohle v letadle a to byl masakr :D Ale trvalo to jen cca 20 minut, Windows CE a i samotny bezici system... No skakat ve filmech neslo - odezva na dotek cca 4-5 vterin, jeste si clovek musel pricist offset, kam ma tuknout, proklikal spoustu chyb ala ze mu chybi font - a cim to teda napsal? . Tohle byl opravdovy masakr :)))

[little.owl]

U projektu na kterym ted prevazne makam, mame limit 300ms po startu musi system plne komunikovat, 1800ms po startu plne funkcni. Jedna z veci, ktera podrizla pouziti Linuxu bylo, ze nikdo nevedel jestli na procesoru, jehoz spec jsme jeste neznali neb byl take pod vyvojem, to lze dosahnout.

[blami]

Vsichni uzivatele Ubuntu :D

[pjoter]

Kdyz to nejake prase navrhne, tak se delaji ruzne prasarny...