abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

dnes 00:55 | Nová verze

Po téměř 13 měsících vývoje od verze 0.11.0 byla vydána verze 0.12.0 hardwarově nenáročného desktopového prostředí LXQt (Lightweight Qt Desktop Environment, Wikipedie) vzniklého sloučením projektů Razor-qt a LXDE. Přehled novinek v příspěvku na blogu.

Ladislav Hagara | Komentářů: 6
včera 12:33 | Zajímavý software

Článek ne Medium představuje nejnovější stabilní verzi 2.0 svobodné decentralizované mikroblogovací platformy a sociální sítě podobné Twitteru Mastodon (Wikipedie). Detailní přehled novinek na GitHubu [Hacker News].

Ladislav Hagara | Komentářů: 0
včera 06:00 | Komunita

V Praze na půdě Elektrotechnické fakulty ČVUT dnes probíhá RT-Summit 2017 – setkání vývojářů linuxového jádra a uživatelů jeho real-time verze označované jako preempt-rt. Přednášky lze sledovat online na YouTube.

Ladislav Hagara | Komentářů: 0
20.10. 14:33 | Zajímavý projekt

Blender Animation Studio zveřejnilo první epizodu z připravovaného animovaného seriálu The Daily Dweebs o domácím mazlíčkovi jménem Dixey. Ke zhlédnutí také ve 3D s rozlišením 8K.

Ladislav Hagara | Komentářů: 0
20.10. 12:34 | Komunita

Aktualizovanou počítačovou hru Warhammer 40,000: Dawn of War III v ceně 39,99 eur běžící také na Linuxu lze o víkendu na Steamu hrát zdarma a případně ještě v pondělí koupit s 50% slevou. Do soboty 19:00 lze na Humble Bundle získat zdarma Steam klíč k počítačové hře Sid Meier's Civilization® III v ceně 4,99 eur běžící také ve Wine.

Ladislav Hagara | Komentářů: 0
20.10. 00:22 | Nasazení Linuxu

Společnost Samsung oznámila, že skrze dokovací stanici DeX a aplikaci Linux on Galaxy bude možno na Samsung Galaxy S8 a S8+ a Galaxy Note 8 provozovat Linux. Distribuce nebyly blíže upřesněny.

Phantom Alien | Komentářů: 19
19.10. 23:55 | Komunita

Společnost Purism na svém blogu oznámila, že její notebooky Librem jsou nově dodávány se zrušeným (neutralized and disabled) Intel Management Engine (ME). Aktualizací corebootu na již prodaných noteboocích lze Management Engine také zrušit. Více v podrobném článku.

Ladislav Hagara | Komentářů: 2
19.10. 21:44 | Nová verze

Organizace Apache Software Foundation (ASF) na svém blogu slaví páté výročí kancelářského balíku Apache OpenOffice jako jejího Top-Level projektu. Při této příležitosti byl vydán Apache OpenOffice 4.1.4 (AOO 4.1.4). Podrobnosti v poznámkách k vydání. Dlouhé čekání na novou verzi tak skončilo.

Ladislav Hagara | Komentářů: 7
19.10. 19:22 | Pozvánky

Již příští týden - 26. a 27. října se v Praze v hotelu Olšanka odehraje OpenWRT Summit. Na webu konference naleznete program a možnost zakoupení lístků - ty stojí 55 dolarů. Čtvrtek bude přednáškový a v pátek se budou odehrávat převážně workshopy a meetingy.

Miška | Komentářů: 1
19.10. 13:44 | Nová verze

Bylo vydáno Ubuntu 17.10 s kódovým názvem Artful Aardvark. Ke stažení jsou Ubuntu Desktop a Server, Ubuntu Cloud Images, Ubuntu Netboot, Kubuntu, Lubuntu a Lubuntu Alternate, Lubuntu Next, Ubuntu Budgie, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio a Xubuntu. Podrobnosti v poznámkách k vydání.

Ladislav Hagara | Komentářů: 25
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (10%)
 (1%)
 (1%)
 (1%)
 (74%)
 (13%)
Celkem 180 hlasů
 Komentářů: 7, poslední 19.10. 23:06
    Rozcestník

    Jaderné noviny - 4. 3. 2009

    3. 4. 2009 | Jirka Bourek | Jaderné noviny | 3493×

    Aktuální verze jádra: 2.6.29-rc7. Citáty týdne: Steven Rostedt, Linus Torvalds, Darren "Slušňák" Hart, Andrew Morton. Aby NetworkManager fungoval při uspávání/probouzení. Přerušení, vlákna a lockdep. Xen: dokončovací práce. Zrychlení vypisování ftrace. Shrnutí interních změn API 2.6.29.

    Obsah

    Aktuální verze jádra: 2.6.29-rc7

    link

    Současné vývojové jádro 2.6 je 2.6.29-rc7 vydané 3. března. Obsahuje dlouhý seznam oprav, nové ovladače pro gigabitové ethernetové adaptéry Atheros L1C, IEEE1394 adaptéry FireDTV a nějaká zlepšení chování v situaci, kdy souborovému systému btrfs dojde volné místo. Detaily vizte v kompletním changelogu.

    Tento týden nebyly vydány žádné stabilní aktualizace 2.6.

    Citáty týdne: Steven Rostedt, Linus Torvalds, Darren "Slušňák" Hart, Andrew Morton

    link

    HAHAHAHHAAAA!!!! Můj ďábelský plán funguje! Pošlu neoptimální kód a nechám ostatní, aby ošklivou práci udělali za mě!!!!

    Eh, neřekl jsem to náhodou nahlas?

    -- Steven Rostedt

    Nejenom že řekl, ale navíc tě zažaluju, protože na tenhle algoritmus mám patent.

    -- Linus Torvalds

    +	/*
    +	 * Pifutex má vlastníka, ujistíme se, že jsme to my, pokud 
    +	 * ne, stěžujeme si do uživatelského prostoru
    +	 * FIXME_LATER: vyřešit to slušně
    +	 */
    +	pid = curval & FUTEX_TID_MASK;
    +	if (pid && pid != task_pid_vnr(current))
    +		return -EMORON;

    -- Darren "Slušňák" Hart (díky Bertu Wesargovi)

    Jo, ve stromě je spousta ošklivého kódu a je smutné, že správci dále začleňují ošklivý kód.

    Tenhle není jednoduché opravit - je potřeba mít na paměti, co je správné, a co špatné, ale nemůžeš se přitom dívat na existující kód, abys zjistit, co je co.

    -- Andrew Morton

    Aby NetworkManager fungoval při uspávání/probouzení

    link

    Každý, kdo cestuje s uspaným laptopem, pravděpodobně narazil na otravný problém NetworkManageru, který se pokouší připojit do staré sítě - do té, kterou jste opustili před nastoupením do letadla. Zdá se, že Dan Williams problém vyřešil a zaslal sadu patchů, které ho opravují. Ovladače přiřazují časové značky wifi sítím, o kterých ví. Tímto způsobem lze zjistit, jestli jsem síť viděl před vteřinou, před sedmi vteřinami, nebo tak dávno, že je pro mě mrtvá. Všechny k tomu ale využívají jaderný čítač 'jiffies'. A 'jiffies' se během uspávání/probouzení nezvyšuje. Už chápete, kam tím mířím? Jon Corbet, autor této zprávičky, plánuje při nejbližší příležitosti koupit Danovi pivo.

    Přerušení, vlákna a lockdep

    link

    Felipe Balbi nedávno zaslal ovladač nazvaný twl4030-pwrbutton, který generuje vstupní události, když někdo stiskne vypínač připojený přes i2c řadič twl4030. V mnoha ohledech je to standardní ovladač; Felipe rozhodně nečekal, že kvůli tomuto zaslání vznikne dlouhá a zatrpklá diskuze, což je ale přesně to, co následovalo. Během této diskuze její účastníci načrtli některé problémy způsobu, jakým jsou v Linuxu obsluhována přerušení, společně s potenciálním řešením.

    Věc začala, když Andrew Morton zpochybnil tento kousek kódu nalezený v obsluze přerušení v ovladači:

    #ifdef CONFIG_LOCKDEP
        /* WORKAROUND pro lockdep, který nám nutí IRQF_DISABLED, což
         * nechceme a nemůžeme tolerovat. Ačkoliv by mohlo být přátelštějští
         * nepůjčovat si kontext tohoto vlákna...
         */
        local_irq_enable();
    #endif

    Workaroundy tohoto druhy bývají středem pozornosti horlivých revidovatelů. Porozumět tomuto konkrétnímu vyžaduje jenom trochu informací.

    Kdysi ve Starých dobrých časech mělo linuxové jádro "rychlé" a "pomalé" obsluhy přerušení; hlavním rozdílem bylo to, že "rychlé" obsluhy běžely se zakázanou obsluhou přerušení, kdežto "pomalé" obsluhy s povolenou. Postupem času se rozdíly mezi těmito typy smazaly; rychlejší a chytřejší hardware a rozšířenější používání softwarových přerušení a taskletů zajistily, že na době zpracovávání přerušení téměř nezáleží. Většina autorů ovladačů tedy příliš nepřemýšlí o tom, jestli píší "pomalou" nebo "rychlou" obsluhu, i když toto rozlišování stále existuje. Pokud ovladač nepředá příznak IRQF_DISABLED, když požaduje přerušovací linku, jeho obsluha přerušení běží s povolenými přerušeními.

    Když je povolen jaderný validátor zámků "lockdep", vytvoří detailní model toho, jak jsou v jádře používány zámky. Tento model lze použít k nalezení potenciálních deadlocků a dalších problémů. Podle Inga Molnára je lockdep poměrně efektivní:

    Také jste si možná všimli, že během posledních 2 až 3 let se počet výskytů výrazu "tvrdé zamrznutí" v hlášeních regresí snížil o řád - a většina z tohoto snížení je spojena s pokrytím lockdepem.

    Ukazuje se nicméně, že vývojáři lockdepu použili jeden významný zjednodušující předpoklad: všechny obsluhy přerušení se vykonávají se zakázanými přerušeními. Když je lockdep povolen, obecná vrstva obsluhy přerušení toto vynutí bez ohledu na to, jestli byla dotyčná obsluha registrována s příznakem IRQF_DISABLED. Lockdep tímto způsobem funguje už nějakou dobu a stížnosti jsou ojedinělé. Nicméně, jak lze vidět z patche citovaného výše, "ojedinělé" není to samé jako "žádné".

    Ovladače zařízení připojených přes I2C pracují s několika zajímavými omezeními, z nichž většina je vynucena tím, že "sběrnice" i2c je ve skutečnosti pomalé dvoudrátové rozhraní. Takže i "rychlé" operace, jako je čtení registru v zařízení, jsou ve skutečnosti u i2c zařízení pomalé; jsou tak pomalé, že proces, který danou operaci provádí, by měl při čekání na výsledek spát. A tady se u obsluhy přerušení i2c zařízení objevuje problém, protože potřebují přistupovat k registrům v zařízení, ale spát nemohou.

    Výsledkem je, že mnoho i2c ovladačů implementovalo něco, co je v podstatě obsluha přerušení ve vláknech. "Skutečné" přerušení jednoduše přerušení zamaskuje a probudí vlákno, které potom udělá skutečnou práci zahrnující komunikaci se zařízením. V případě ovladače twl4030 byla implementace ve vláknech provedena relativně formálním způsobem, ve kterém jsou zavolány obsluhy přerušení zařízení - ze speciálního jaderného vlákna - samotnou IRQ vrstvou. Tyto obsluhy ve vláknech nečekají, že by běžely se zakázaným přerušením - vskutku tak běžet nemohou - ale obecný IRQ kód přerušení vypne i tak, pokud je povolen lockdep. To je důvod, proč si tento patch přidělává potíže tím, že je zase zapne, když se lockdep používá.

    V reakci na tuto diskuzi Peter Ziljstra zaslal patch, který vynucuje IRQF_DISABLED u všech ovladačů. Jeho argumentem bylo, že žádná obsluha přerušení by neměla běžet s povolenými přerušeními. Umožnit to znamená koledovat si o přetečení jaderného zásobníku, pokud přijde mnoho do sebe se vnořujících přerušení; také to, říká, podporuje povědomí o tom, že pomalé obsluhy přerušení jsou OK. Navíc by ovladače měly být schopny vykonávat obsluhu přerušení se zakázaným přerušením, protože na sdílené lince může přerušení zakázat jiný ovladač. Takže nedává smysl "opravit" lockdep tak, aby některé obsluhy mohly běžet s povoleným přerušením; místo toho by měl být předpoklad 'vždy zakázané' přenesen do systému jako celku.

    Odpověď na tento patch byla povětšinou souhlasná, alespoň obecně. Nastavit IRQF_DISABLED jako výchozí dává pro většinu zařízení smysl. Jsou však ovladače, které potřebují běžet s povoleným přerušením; například IDE ovladače, které používají programované I/O (PIO). Pokud bude těmto obsluhám dána exkluzivní kontrola nad systémem, ostatní zařízení budou mít neakceptovatelné latence, operace budou selhávat nebo se začnou zahazovat data. Jakákoliv změna tohoto typu tedy musí být provedena opatrně a musí zůstat možnost, aby obsluha běžela s povoleným přerušením.

    A vynucení IRQF_DISABLED samozřejmě nijak nepomáhá vyřešit problém s twl4030.

    Skutečným řešením by bylo mít obecnou podporu pro obsluhy přerušení ve vláknech. Strom realtime preempce takové obsluhy podporuje již nějaký čas; nedávno byl zaslán patch s variantou obsluhy ve vláknech ke zvážení pro hlavní řadu. Obsluhy přerušení ve vláknech mají mnoho výhod i nad rámec řešení problému diskutovaného zde; mohou zlepšit latence, umožnit priorizovat obsluhy přerušení a časem možná umožnit úplné odstranění softwarových přerušení. Zdá se tedy, že by mělo cenu tento kód začlenit.

    Za tímto účelem se Thomas Gleixner vrátil s novou verzí patche obsluh ve vláknech. API vypadá v podstatě stejně jako v předchozí verzi, ale mohlo by se změnit v reakci na některé komentáře v revizích, které se objevily. Tato infrastruktura v podstatě umožňuje ovladači registrovat "rychlou obsluhu", která potvrdí (a zamaskuje) přerušení; pak zde je také běžná obsluha, která se zavolá buď v tvrdém [hard] přerušení nebo v kontextu procesu v závislosti na návratové hodnotě rychlé obsluhy. API umožňuje ovladačům dál fungovat bez modifikací nebo se změnit a používat obsluhu ve vláknech.

    David Brownell, vedoucí kritik chování lockdepu a nápadu zakázat přerušení pro všechny obsluhy, zdá se, souhlasí s tím, že obsluha přerušení ve vláknech by měla být schopna vyřešit problém i2c. Všechny obsluhy přerušení ve vláknech z nutnosti poběží s povolenými přerušeními, takže hlavní potíž mizí. David by rád viděl nějaké změny, které by umožnily lepší podporu zřetězení obsluh, které je v takových situacích typicky potřeba, ale není jasné, kolik změn je skutečně zapotřebí.

    Ve shrnutí se zdá, že obsluhy přerušení ve vláknech budou další technologií, která bude převzata ze stromu realtime preempce. Je nicméně otázka, kdy se tak stane. Požadavek na změny API může věci poněkud zpomalit; také se objevily požadavky na příklady implementace obsluhy ve vláknech u různých typů ovladačů. Uspokojit tyto požadavky dost rychle, aby se stihly revize kódu před začleňovacím oknem 2.6.30, je tak trochu výzva. Tento kód by tedy mohl čekat o vývojový cyklus víc; bylo by ale překvapivé, kdyby to trvalo déle.

    Xen: dokončovací práce

    link

    Bylo nebylo, Xen byl horké téma, co se virtualizace týče. Vývojáři Xenu měli fungující řešení pro Linux - používající svobodný software - v mnohem pokročilejším stavu než všichni ostatní a Xen se zdál být budoucností virtualizace v Linuxu. Poté následovalo mnoho spekulativního kapitálu, distributoři se předháněli v tom, kdo první nabídne virtualizaci založenou na Xenu. Zdá se ale, že během cesty se Xen ztratil. Vývojáři XenSource často dávali najevo svůj malý zájem o začlenění kódu do hlavní řady a pokusy ostatních to udělat narážely na nekončící množství překážek. Xen tedy zůstal po mnoho let mimo hlavní řadu; první veřejné vydání Xenu se objevilo roku 2003, ale základní kód Xenu byl začleněn až do 2.6.23 v říjnu 2007.

    Mezitím se objevilo KVM a převzalo většinu pozornosti. Jeho cesta do hlavní řady byla oslnivě rychlá a mnoho jaderných vývojářů se nestydělo vyjadřovat své preference přístupu, který KVM používá. Nedávno Red Hat věci trochu formalizoval oznámením "virtualizační agendy" založené na KVM. Mezitím se objevil lguest jako rychlý úvod pro ty, kteří si chtějí hrát s virtualizačním kódem.

    Příběh o Xenu je klasický příklad odůvodněnosti pravidla "nejprve do upstreamu", které říká, že kód by měl být nejprve začleněn do hlavní řady předtím, než je distribuován zákazníkům. Distributoři chvátali s tím, aby mohli Xen dodávat, načež zjistili, že podporují kód mimo strom, který často nebyl podporován svými autory. Vydávané verze Xenu konkrétně často fungovaly pouze se starými jádry, což přidělávalo spoustu práce distributorům, kteří chtějí dodávat něco současnějšího. Přinejmenším někteří z těchto distributorů nyní přecházejí k jiným řešením a jaderní vývojáři na nejvyšších úrovních zpochybňují, jestli v současnosti vůbec má cenu začleňovat zbývající kód Xenu.

    Shrnuto se zdá, že Xen má před sebou svou poslední hodinku. A nebo možná byly pověsti o skonu Xenu poněkud přehnané.

    Kód v hlavní řadě implementuje koncept Xen "DomU" - neprivilegované domény bez přístupu k hardwaru. Plná implementace Xenu nicméně vyžaduje víc než to; je zde hypervizor v uživatelském prostoru (který má licenci GPL) a jaderný kód "Dom0". Dom0 je první doména, kterou spouští hypervizor; typicky běží s více privilegii než ostatní hosté Xenu. Účelem Dom0 je opatrně předávat privilegia dalším doménám Xenu, poskytovat jim přístup k hardwaru, síťovým rozhraním atd. podle nastavení správcovské politiky. Skutečná implementace Xenu musí obsahovat kód Dom0 - v současnosti velký kus kódu mimo strom.

    Jeremy Fitzhardinge by tuto situaci rád změnil. Zaslal sadu patchů jádra Xen Dom0 s cílem začlenit ji do 2.6.30. Mezi komentáři revidovatelů byl tento dotaz Andrewa Mortona:

    Nejsem rád, že jsem ten, kdo tohle řekne, ale měli bychom se posadit a zjistit, jestli je ospravedlnitelné začlenit cokoliv z toho do Linuxu. Stále si myslím, že se jedná o případ, kdy jde technologie Xenu "starou" cestou a svět se přesouvá k "novému" směru, ke KVM.

    Nebudeme během tří let litovat toho, že jsme to začlenili?

    Otázky, které Andrew položil, byly v podstatě (1) jaký kód (kromě v současnosti zaslaného) je potřeba k dokončení práce a (2) je opravdu důvod to dělat? Odpověď na první otázku je další dvě až tři podobně velké série, které zajistí, že bude možné nabootovat dom0 bez dalších úprav. Potom jsou zde další kousky, které se do hlavní řady možná nikdy nedostanou. Začlenění hlavních částí do hlavní řady, říká Jeremy, by nicméně zmenšilo patche mimo strom, které musí udržovat distributoři a obecně všem zjednodušilo život. Co se druhé otázky týče, Jeremy odpovídá:

    Bez ohledu na všechen hluk o KVM v jaderných kruzích má Xen rozsáhlou a rostoucí základnu instalací. V současnosti tyto instalace běží na obrovských patchích mimo strom, z čehož nikdo šťastný není. Nejlepší bude, když to bude v hlavní řadě. Chápeš, jako to říkáme u všeho ostatního.

    Krom toho Jeremy argumentuje, že Xen má stále důvod k existenci. Jeho návrh je mnoha způsoby zásadně odlišný od KVM; excelentní popis těchto rozdílů vizte v této zprávě. Výsledkem je, že Xen je užitečný v odlišných situacích:

    Některé výhody, které Jeremy popisuje, zahrnují:

    • Přístup Xenu k tabulkám stránek odstraňuje potřebu stínových tabulek stránek [shadow page tables] nebo vnořování tabulek stránek [page table nesting] v hostech; to u mnoha druhů zátěže významně zlepšuje výkonnost.

    • Hypervizor Xenu je odlehčený a může běžet samostatně; hypervizor KVM je místo toho v jádře. Zdá se, že někteří výrobci (jmenováni jsou HP a Dell) dodávají hypervizor Xenu v mnoha svých systémech; jedná se mezi jinými věcmi o kód za vlastností "okamžité zapnutí" [instant on].

    • Podpora paravirtualizace v Xenu mu umožňuje fungovat na hardwaru, který nepodporuje plnou virtualizaci. KVM potřebuje podporu v hardwaru.

    • Oddělení hypervizoru Dom0 a DomU zjednodušuje bezpečnostní ověřování. Oddělení domén také umožňuje divoké konfigurace, ve kterých je každé zařízení řízeno jinou doménou; dalo by se to považovat za určitý druh těžkotonážní architektury mikrojádra.

    Naproti tomu výhody KVM mají podobu relativní jednoduchosti, snadného používání, plného přístupu k současným vlastnostem jádra atd. Podle Jeremyho mají oba způsoby v Linuxu své místo.

    Relativní ticho na konci diskuze naznačuje, že Jeremy se svou argumentací uspěl. V historii Xenu možná došlo k chybám, ale jde o projekt, který je stále naživu a má zjevně důvody k existenci. Autor článku předvídá, že kód Dom0 se setká v začleňovacím okně 2.6.30 jenom s malým odporem.

    Zrychlení vypisování ftrace

    link

    Jaderný patch, který snižuje spotřebu paměti a zároveň poskytuje přibližně trojnásobné zlepšení výkonnosti je obecně považován za dobrou věc. Nicméně, pokud je k dispozici další, víceméně ekvivalentní - ale mnohem rychlejší - způsob, jak danou akci provést, lze ho prohlásit za zbytečnou optimalizaci. Nedávný patch funkce ftrace_printk() má tyto vlastnosti, nicméně možnost získat takovéto zrychlení, i když v něčem, co je spíš pohodlné než potřebné, by mohlo trumfovat nad obavami o potřebnosti.

    Lai Jiangshan navrhl přidání binární verze ftrace_printk() loni v prosinci; Frederic Weisbecker tyto patche převzal a zaslal k začlenění do ftrace. Základním nápadem je, že místo konverze argumentu na řetězec - jak to specifikuje formátování argumentů ve stylu printk() - by ftrace_bprintk() odložilo skutečnou konverzi až do doby, kdy je výstup čten z uživatelského prostoru. Místo toho by se do kruhového bufferu ukládaly binární hodnoty s ukazatelem na formátovací řetězec. Když se data sledování čtou z debugfs, formátovací řetězec a binární data jsou poskládána do výstupu.

    Ingovi Molnárovi se tento přístup líbil, ale není spokojen s tím, že duplikuje většinu kódu v vsnprintf() ve dvou nových funkcích. Navrhl, že by mělo být možné vytáhnout společný kód: Měli bychom se mnohem více snažit sjednocovat tyto funkce místo vzdávání se a jejich duplikování. Frederic souhlasil, což nakonec vedlo k patchi, který dělí dekódování formátovacího řetězce do samostatné funkce.

    Ingo také požádal o nějaká čísla, co se výkonnosti týče, ty Frederic poskytl jako součást patche. Rozdíl v paměti a čase zjistil přidáním:

    ftrace_printk("This is the timer interrupt: %llu", jiffies_64);

    do přerušení časovače. Spotřeba paměti byla méně než poloviční (16 versus 39 bytů na záznam) a úspora času byla také významná:

    Po nějakém čase běhu bez zatížení (žádné X, žádné skutečně aktivní procesy):

    ftrace_printk:  duration average: 2044 ns, avg of bytes stored per entry: 39
    ftrace_bprintk: duration average: 1426 ns, avg of bytes stored per entry: 16

    Vyšší zátěž (nastartovaná X a cat běžící na konzoli v X, který cyklicky čte výpisy sledování):

    ftrace_printk:  duration average: 8812 ns
    ftrace_bprintk: duration average: 2611 ns

    Andrew Moton byl poněkud zmaten ze záměru patche: Snažit se zrychlit něco, co je z principu pomalé, se zdá být... divné. Ingo ale vysvětlil, proč to dává smysl:

    Nejrychlejší způsob sledování je zjevně znát přesné rozvržení argumentu a mít specifický kus kódu v C, který tvoří sledovací bod a předává tato data do kruhového bufferu. Většina sledovacích bodů je takto udělána.

    To ale neodstraňuje jednoduchost používání ad-hoc sledování funkcemi podobnými printk - a zrychlit je třikrát je rozumný cíl.

    Rozdělení formátovacího řetězce do jeho vlastní funkce format_decode() se z většiny setkalo se souhlasem, až na to, že seznam argumentů je poněkud ošklivý:

    int format_decode(const char *fmt, enum format_type *type, 
                      int *flags, int *field_width, int *base, 
                      int *precision, int *qualifier)

    Linus Torvalds navrhl použít struct printf_spec k uložení různých hodnot dekódovaných ze specifikace formátu a před funkce ukazatel na ni. Frederic souhlasil a přidal to do svých patchů, ale nedostal se s tím dostatečně daleko.

    Linus si také myslel, že různým pomocným funkcím, které obsluhují specifické formáty (např. number(), pointer(), string() atd.) by se také měl předávat ukazatel na struct printf_spec. Jak upozorňuje: Když už pročišťujeme, tak to udělejme pořádně. Frederic opět rychle souhlasil; plánuje znovu zaslat patche reagující na tyto a další komentáře v blízké budoucnosti.

    Krom toho, protože ftrace_bprintk() je náhrada za ftrace_printk(), navrhuje Frederic odstranění současného kódu ve prospěch rychlejší verze. Ingo tento přístup obhajuje:

    No, ftrace_bprinkt() se mi zdá být vhodnou a transparentní náhradou ftrace_printk(). Tj. pojďme ji prostě používat jako novou implementaci ftrace_printk().

    I když jde o menší vylepšení relativně malého jaderného subsystému, poskytuje docela působivé zlepšení výkonnosti. Proces revidování jako bonus vyústil v nějaká pročištění, které pravděpodobně mělo být provedeno již dávno. I když platí argument, že tato úprava není skutečně zapotřebí, není příliš rušivá ani není příliš velká. To nakonec pravděpodobně bude dost k tomu, abychom ji nakonec viděli v hlavní řadě.

    Shrnutí interních změn API 2.6.29

    link

    Jak se vývojový cyklus 2.6.29 blíží ke svému zakončení, je vhodné podívat se na interní změny API, ke kterým došlo. Následující seznam nemůže ani zdaleka být vyčerpávající, ale snad zachycuje hlavní body.

    • Ohromná sada patchů osobních údajů [credentials] byla začleněna. Tento kód reorganizuje správu osobních údajů procesu (ID uživatele, kvalifikace atd.) Jedním z okamžitých důsledků této změny je to, že přímé odkazování se na pole zaměřená na osobní údaje ve struktuře úlohy musí být změněno; například current->user->uid se mění na current_uid(). Popis nového API vizte v Documentation/credentials.txt.

    • Kód ftrace se dočkal mnoha interních změn. Sledování funkcí bylo v mnoha ohledech vylepšeno a vývojáři přidali mechanismus pro profilování chování příkazu if, poskytnutí grafu volání funkcí, získání sledování zásobníku v uživatelském prostoru a sledování přechodů mezi stavy napájení.

    • Většina funkcí/metod zpětných volání spojených se strukturou net_device byla z této struktury přesunuta do nové struct net_device_ops. Ovladače ve stromě byly konvertovány na nové API.

    • Ze struktury struct net_device; bylo odstraněno pole priv; ovladače by místo něj měly používat netdev_priv().

    • Obecná vrstva PHY má nyní podporu pro správu napájení. Za tímto účelem byly do struct phy_driver přidány dvě nové metody - suspend()resume().

    • Síťová vrstva nyní podporuje operaci odlehčování při rozsáhlém příjmu [large receive offload] (či "obecné odlehčování při příjmu").

    • API NAPI bylo trochu pročištěno. Konkrétně funkce jako netif_rx_schedule(), netif_rx_schedule_pred()netif_rx_complete() ztratily nepotřebný parametr struct net_device.

    • Souborová operace poll() nyní může spát; více informací o této změně vizte v tomto článku.

    • Mechanismus masek CPU, který se používá k reprezentaci sady procesorů v systému, je uprostřed rozsáhlého přepracování. Problém spočívá v tom, že masky CPU se často ukládají na zásobník, ale s tím, jak počet CPU roste, na zásobníku není pro masku dost místa. Nové API je navrhováno tak, aby tyto masky ze zásobníku zmizely a aby existovala ochrana proti tomu, kdyby se někdo někdy snažil je tam uložit. Detaily o této práci vizte v tomto oznámení od Rustyho Russela.

    • Byla začleněna infrastruktura pro asynchronní volání funkcí. Tento kód je nicméně stále ve vývoji a co se 2.6.29 týče, nebude aktivován při absenci parametru příkazové řádky jádra fastboot.

    • Byly začleněny funkce pro exkluzivní alokace I/O paměti.

    • Je zde nové synchronní hashovací rozhraní nazvané "shash". Zjednodušuje použití synchronních hashovacích operací a přitom umožňuje použít stejné tfm simultánně v různých vláknech. Všichni uživatelé ve stromě byli přepracováni na nové API.

    • Kód časovačů s vysokým rozlišením byl zjednodušen odstraněním proměnných režimů funkcí zpětných volání. Všechno zpracování nyní probíhá v kontextu tvrdého IRQ (hardirq).

    • Byla přidána nová sada LSM háčků; tyto podporují bezpečnostní operace založené na cestách [pathname]. Se začleněním těchto háčků byla odstraněna jedna hlavní překážka začlenění bezpečnostních modulů jako AppArmor a TOMOYO.

    • Jádro se nyní odmítne přeložit s GCC 4.1.0 nebo 4.1.1; tyto verze mají nepříjemné chyby, které brání vytvoření funkčního jádra. Verze 3.0 a 3.1 byly také prohlášeny za příliš staré a v 2.6.29 nebudou podporovány.

    • Ovladače Video4Linux nyní používají oddělenou strukturu v4l2_file_operations, ve které se ukládají jejich jako-VFS zpětná volání. Prototypy mnoha z těchto funkcí byly změněny, byl odstraněn parametr inode.

    • >Video4Linux2 nyní získal koncept "podzařízení", který má odrážet fakt, že video "zařízení" ve skutečností bývá sestava několika spolupracujících zařízení. Popis toho, jak tento mechanismus funguje, vizte v novém dokumentu.

    • Dvě nové funkce - stop_machine_create()stop_machine_destroy() - umožňují nezávislé vytváření vláken používané funkcí stop_machine(). To umožňuje vytvořit tato vlákna před skutečným pokusem stroj zastavit, čímž je celá operace odolnější proti selhání.

    • Exporty mnoha SUNRPC funkcí byly změněny na pouze GPL.

    • Interní API MTD (memory technology device, zařízení paměťové technologie) doznalo významných změn zaměřených na podporu větších zařízení (těch, které vyžadují 64bitové velikosti.)

    Vývojáři, které zajímá historie API změn, se mohou podívat na stránku API změn 2.6 na LWN. Po období nešťastného zanedbávání je tato stránka opět aktuální; Jon Corbet slibuje, že v udržování této stránky bude v budoucnu mnohem důslednější.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    saly avatar 3.4.2009 01:08 saly | skóre: 22 | blog: odi_et_amo
    Rozbalit Rozbalit vše Re: Jaderné noviny - 4. 3. 2009

    Kdyby nacpali XEN do mainstreamu, tak by to bylo fajn. Myslel jsem, že už je to dávno mrtvé a s nepodporou hw virtualizace mam prostě u KVM smůlu.

    Třeba se ještě někdy dočkám ve vanille podporu paravirtualizace :-)

    3.4.2009 17:09 thingie
    Rozbalit Rozbalit vše Re: Jaderné noviny - 4. 3. 2009

    Vanilla kernel se dá zkompilovat jako User mode linux, což bych osobně pro mnoho použití považoval za lepší. Minimálně není nutný žádný zásah do hostitelského systému. A pokud chce někdo provozovat něco "velkého", ať si to holt zpatchuje nebo koupí něco co umí KVM. Což.

    saly avatar 3.4.2009 17:17 saly | skóre: 22 | blog: odi_et_amo
    Rozbalit Rozbalit vše Re: Jaderné noviny - 4. 3. 2009

    Kdo mluví o něčem velkém? Já si chci jenom na notebooku pustit jednu, dvě virtuální mašiny na hraní :-)

    3.4.2009 17:21 thingie
    Rozbalit Rozbalit vše Re: Jaderné noviny - 4. 3. 2009

    Tak to UML vede.

    3.4.2009 10:23 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše překlep
    V části o Xenu "plnéhho přístup" má být "plného přístupu".
    3.4.2009 12:20 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: překlep
    Dík, opraveno.
    4.4.2009 12:48 dusan
    Rozbalit Rozbalit vše Re: Jaderné noviny - 4. 3. 2009

    HAHAHAHHAAAA!!!! Můj ďábelský plán funguje! Pošlu neoptimální kód a nechám ostatní, aby ošklivou práci udělali za mě!!!! Eh, neřekl jsem to náhodou nahlas?

    Steven Rostedt

    Nejenom že řekl, ale navíc tě zažaluju, protože na tenhle algoritmus mám patent.

    Linus Torvalds

     

    Skoro som spadol zo stoličky :-) :-)

    4.4.2009 13:04 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Jaderné noviny - 4. 3. 2009
    Vzpomínám si na jinou podobnou Linusovu hlášku - "Ten kód jsem netestoval, od toho jsou uživatelé."
    Quando omni flunkus moritati

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.