Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
Canonical vydal Ubuntu Core 24. Představení na YouTube. Nová verze Ubuntu Core vychází z Ubuntu 24.04 LTS a podporována bude 12 let. Ubuntu Core je určeno pro IoT (internet věcí) a vestavěné systémy.
Databáze DuckDB (Wikipedie) dospěla po 6 letech do verze 1.0.0.
Intel na veletrhu Computex 2024 představil (YouTube) mimo jiné procesory Lunar Lake a Xeon 6.
Na blogu Raspberry Pi byl představen Raspberry Pi AI Kit určený vlastníkům Raspberry Pi 5, kteří na něm chtějí experimentovat se světem neuronových sítí, umělé inteligence a strojového učení. Jedná se o spolupráci se společností Hailo. Cena AI Kitu je 70 dolarů.
Byla vydána nová verze 14.1 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
Společnost Kaspersky vydala svůj bezplatný Virus Removal Tool (KVRT) také pro Linux.
Grafický editor dokumentů LyX, založený na TeXu, byl vydán ve verzi 2.4.0 shrnující změny za šest let vývoje. Novinky zahrnují podporu Unicode jako výchozí, export do ePub či DocBook 5 a velké množství vylepšení uživatelského rozhraní a prvků editoru samotného (např. rovnic, tabulek, citací).
Byla vydána (𝕏) nová verze 7.0 LTS open source monitorovacího systému Zabbix (Wikipedie). Přehled novinek v oznámení na webu, v poznámkách k vydání a v aktualizované dokumentaci.
Současné vývojové jádro je 2.6.36-rc7 vydané 6. října. Mělo by to být poslední -rc, nevidím žádný důvod zdržovat vydání. Stále bylo více změn v drivers/gpu/drm, než bych doufal, ale všechny vypadají neškodně a dobře. Skvělá to poslední slova. Zkrácený changelog je v oznámení; na kernel.org najdete kompletní changelog.
Stabilní aktualizace: 2.6.32.24 obsahující jedinou chybu překlepu v kódu Xenu bylo vydáno 1. října. V době psaní tohoto článku se žádné stabilní aktualizace nerevidují.
napsal Jonathan Corbet, 6. října 2010
Architektura PowerPC je obvykle považována za doménu big-endian – nejvýznamnější byte vícebytové hodnoty je první. Big-endian je konzistentní s mnoha jinými architekturami, ale fakt, že jedna obskurní architektura – x86 – je little-endian, znamená, že svět jako celek tíhne na stranu little-endian. Přinejmenším některé procesory PowerPC nicméně mohou běžet v režimu little-endian, takže Ian Munsie zaslal sadu patchů, která Linuxu umožňuje tuto vlastnost využít.
První otázka, která několika vývojářům přišla na mysl, byla: „proč?“ PowerPC běhá v režimu big-endian dobře a po podpoře little-endian moc lidí nevolalo. Krom toho endianita vypadá jako jedna z těch věcí, na které mají uživatelé vyhraněné názory; přinejmenším několik uživatelů PowerPC považuje little-endian za levné, špatné a PCčkovité.
Odpovědí, jak ji vyjádřil Ben Herrenschmidt, je podle všeho grafický hardware. Mnoho GPU, obzvláště těch, které jsou zaměřeny na embedded aplikace, funguje jenom v režimu little-endian. Pečlivě napsané grafické ovladače mohou toto omezení obejít bez větších problémů, ale kód v uživatelském prostoru – který si často musí s grafickým hardwarem povídat – je úplně jiná záležitost. Oprava tohoto kódu není něco, do čeho by se někdo chtěl pustit. Výsledkem je tedy to, že procesory PowerPC nejsou zvažovány tam, kde je potřeba podpora pro little-endian. Spustit procesor v tomto režimu je tedy hezká cesta, jak tuto překážku obejít.
Bude nicméně zapotřebí ještě nějaký čas, než bude tato podpora všeobecně k dispozici. Jaderné patche podle všeho vypadají dobře, ale je tu celá sada nástrojů, která je zapotřebí a která není obecně dostupná. Dokud nebude tato malá záležitost vyřešena, PowerPC zůstane klubem pouze pro uživatele big-endian.
napsal Jake Edge, 6. října 2010
Modul důvěryhodné platformy [trusted platform module, TPM] dostupný na mnoha dnešních systémech lze použít mnoha způsoby, od kompletně uzamčených systémů, které uživatel nemůže změnit, po ochranu citlivých informací proti různým útokům. Zatímco architektura pro kontrolu integrity [integrity measurement architecture, IMA], která může ověřit integritu běžícího linuxového systému, je již nějakou dobu v jádře, s ní spojený modul pro rozšířené ověřování [extended verification module, EVM] se do hlavní řady nedostal. Jedna z hlavních námitek proti EVM spočívala v tom, že se kryptografický klíč, který se používá pro ověření integrity, získal z uživatelského prostoru – což v podstatě anuluje garance integrity, které má EVM poskytnout. Sada patchů, které byly nedávno zaslány do e-mailové konference linux-security-module ke komentování, by do jádra přidala dva nové typy klíčů, které by umožnily uživatelskému prostoru poskytnout klíč, aniž by měl přístup k jeho datům.
Naposledy jsme se na EVM dívali v červnu, kdy se zdálo, že by se mohl dostat do 2.6.36. K tomu nedošlo a EVM nebyl začleněn ani do linux-next, takže jeho cesta do hlavní řady je v tomto okamžiku poměrně nejistá. EVM počítá hodnoty HMAC (hash-based message authentication code) pro soubory na disku, použije EVM klíč a TPM k podepsání těchto hodnot, a pak je uloží v rozšířených atributech (xattr) ve jmenném prostoru security. Pokud je EVM klíč prozrazen, s integritou systému lze udělat rychlý konec. I když mají být používány v EVM, bylo by patche přidávající podporu pro typy důvěryhodného a zašifrovaného klíče od Mimiho Zohara možno využít k jiným účelmům jako je například práce s klíči pro šifrování souborového systému.
Základní myšlenkou je to, že by tyto klíče generovalo jádro a uživatelský prostor by se k nim nikdy nedostal v nezašifrované podobě. Zašifrované „bloby“, které by obsahovaly klíče, by jádro k dispozici uživatelskému prostoru dát mohlo. Ten by je mohl například někam uložit, ale pro cokoliv mimo jádro by byly naprosto neprůhledné. Patche přicházejí s dvěma novými příchutěmi těchto klíčů v jádře: důvěryhodnými [trusted] a šifrovanými [encrpyted].
Důvěryhodné klíče generuje TPM a šifruje je pomocí kořenového klíče úložiště TPM [storage root key, SRK], což je 2048 bitový RSA klíč. (To je v terminologii TPM známo jako „zapečetění“ klíče.) Důvěryhodné klíče lze také zapečetit oproti konkrétní sadě hodnot konfiguračních registrů platformy TPM [platform configuration register, PCR], aby klíče nebylo možné odpečetit, pokud se hodnoty nebudou shodovat. PCR obsahuje kontrolu integrity BIOSu systému, zavaděče a operačního systému, takže spojení klíčů s hodnotami PCR znamená, že k důvěryhodným klíčům není možné přistupovat mimo systémy, pro které byly původně určeny. Jakákoliv změna kódu níže povede na klíč, který nepůjde dešifrovat.
Vzhledem k tomu, že hodnoty PCR se mění v závislosti na tom, jaké se použije jádro a initramfs, důvěryhodné klíče lze aktualizovat tak, aby používaly různé PCR, které byly přidány do klíčenky [keyring] (takže existující hodnoty PCR byly ověřeny.) Také může být několik verzí jediného důvěryhodného klíče, každá bude zapečetěna jinými hodnotami PCR – to lze použít k podpoře bootování různých jader, která používají stejný klíč. I když se nešifrovaná data klíče nebudou muset pro různá jádra měnit, blob pro uživatelský prostor se změní kvůli odlišným hodnotám PCR, což povede na nutnost mít v uživatelském prostoru nějakou správu klíčů.
Zašifrované klíče na druhou stranu nezávisí na TPM a místo toho používají jaderné šifrování AES, které je rychlejší než šifrování s veřejným klíčem v TPM. Klíče se generují jako náhodná čísla požadované délky z jaderné zásoby náhodných čísel a když jsou exportovány do uživatelského prostoru jako bloby, jsou zašifrovány hlavním [master] klíčem. Hlavní klíč může být nový typ důvěryhodného klíče, nebo typ klíče, který již v jádře existuje. Samozřejmě pokud hlavní klíč nebude důvěryhodný klíč, bude nutné s ním pracovat zabezpečeně, protože poskytuje zabezpečení dalších zašifrovaných klíčů.
Bloby pro uživatelský prostor obsahují HMAC, který jádro může použít k ověření integrity klíče. Ke generování klíčů, jejich přidávání do jaderné klíčenky a vytažení blobu s klíčem z jádra lze použít utilitu keyctl (nebo systémové volání keyctl()). Sada patchů dává několik příkladů, jak pomocí keyctl manipulovat jak s důvěryhodnými, tak se zašifrovanými klíči.
Nedávný návrh jaderného API pro subsystém crypto nebyl přijat příliš dobře, částečně protože se neintegroval s existujícím API jaderných klíčenek, ale Mimiho návrh tento problém nemá. Oba obsahují možnost balení klíčů do neprůhledných blobů předtím, než se vydají uživatelskému prostoru, ale crypto API šlo o mnoho dál a přidalo spoustu způsobů, jak klíče použít pro šifrování a dešifrování z uživatelského prostoru.
I když by typy pro důvěryhodné a zašifrované klíče byly užitečné pro jaderné služby (jako je EVM či šifrování souborových systémů), nejsou příliš užitečné pro aplikace, které chtějí používat šifrování, aniž by se uživatelskému prostoru zpřístupnily klíče. Klíče by potenciálně mohly používat kryptografické akcelerátory nebo by je možná bylo možné zadrátovat do existujících šifrovacích služeb jádra, ale neposkytnou všechny různé algoritmy, které si představovalo API crypto.
Existující kód IMA řeší jenom část problému s integritou, detekci offline útoků proti souborům na disku (tj. připojení disku pod jiným OS) přenechává EVM. Pokud bude EVM někdy přidáno do jádra, aby se tak dokončilo puzzle ověřování integrity, bude potřeba důvěryhodné klíče nebo něco podobného. Patche zatím přitáhly jenom málo komentářů a stížností, ale zatím byly poslány pouze do různých mailových konferencí týkajících se bezpečnosti v Linuxu – mučírnou linux-kernel si ještě neprošly.
napsal Jonathan Corbet, 5. října 2010
Jaderní vývojáři již dlouho akceptují, že ve většině situacích nelze narušit ABI pro uživatelský prostor. Co se ale stane, když je současné ABI chybné nebo blokování změn představuje riziko, že se vývoj jádra zastaví úplně? V nedávných diskuzích byly naznačeny obě tyto možnosti.
Ovladač capi poskytuje řídící rozhraní pro ISDN adaptéry – které se zjevně někde ještě používají. Pokud lze věřit souboru devices.txt, pak řídícím zařízením pro CAPI aplikace by měl být /dev/capi20, zatímco první aplikace se zobrazí jako /dev/capi20.00 Aplikace by ale zjevně chtěly něco jiného, takže Marc-Andre Dahlhaus zaslal patch, který přesouvá zařízení aplikací do jejich vlastního adresáře. Jinými slovy by se první CAPI aplikace zobrazila jako /dev/capi/0. Patch také modifikuje devices.txt, aby odrážel nové pojmenování.
Alan Cox patch odmítl s tím, že:
Udržování ABI je normálně správné, ale toto odůvodnění má tentokrát pár problémů. První je, že zjevně jenom málo distribucí (pokud vůbec nějaká) dodržuje pravidla popsaná v devices.txt; skutečné ABI bude v praxi odlišné. A za druhé: devices.txt nedodržuje ani jádro: současnou praxí je vytvářet /dev/capi jako řídící zařízení a /dev/capi0 jako první zařízení aplikace. Část z toho překryl virtuální souborový systém capifs, ale capifs je na odchodu z jádra.
Krátkodobě se tedy zdá, že oprava spočívá v redefinici současného chování jako překlepu a vyladění věcí jenom tak, aby udev byl schopen vytvářet správná jména souborů. Soubor devices.txt se zatím měnit nebude. Jestliže se ale objeví regrese, možná bude nutné do budoucna podporovat pro tato zařízení i alternativní jména.
Jean Pihet nedávno zaslal sadu změn sledovacích bodů pro události spojené s napájením. Patch přidával pár nových sledovacích bodů, přidával informace do jiných a přidal i nějakou dokumentaci. O něco později Thomas Renninger přišel s jinou sadou změn sledovacích bodů napájení, která měla věci pročistit a sledovací body trochu zpřístupnit ARM systémům. V obou případech Arjan van de Ven byl proti těmto patchům s tím, že se jedná o rozbití ABI.
Toto ABI má své uživatele – nástroje jako powertop a pytimechart. Zdá se, že Intel má také „interní nástroje“, které by tato změna postihla. Jak to řekl Arjan: problém s ABI spočívá v tom, že nevíš, kolik uživatelů máš. Když se věci vyjádří takto, vypadá to jako standardní případ ABI pro uživatelský prostor, které je nutné zachovávat, ale ne všichni vývojáři to tak vidí.
Peter Zijlstra argumentuje, že nástroje používající sledovací body musí být flexibilnější:
Steven Rostedt má obavy z vlivů ABI sledovacích bodů na vývoj jádra:
Záležitost s ABI sledovacích bodů se v minulosti již několikrát objevila, ale vyřešena nebyla nikdy. V jiných situacích Linus řekl, že jakékoliv jaderné rozhraní, které začnou používat aplikace, se stává součástí ABI, ať už tak bylo zamýšleno nebo ne. Z tohoto úhlu pohledu již nejde o to, jestli někdo „řekne“, že ABI tu je nebo není; aplikace sledovací body používají, takže ke škodě už došlo. Vzhledem k tomu, že vývojáři pro uživatelský prostor jsou často tlačeni k tomu, aby v různých situacích používali sledovací body, dává smysl jim nabídnout stabilní rozhraní.
Na druhou stranu je naprostá pravda, že sledovací body jsou zaháčkované hluboko do jádra. Jestli je opravdu není možné změnit, pak (1) jsou vážně omezeny změny jádra samotného, nebo (2) začneme hromadit zpětně kompatibilní sledovací body, které čím dál tím více nebudou mít souvislost s tím, co jádro skutečně dělá. Ani jedna z těchto možností nepovede na rychlý vývoj jádra v budoucích letech.
A když nic jiného, pokud se sledovací body začnou považovat za součást ABI pro uživatelský prostor, bude silný odpor proti tomu přidávat do jádra další.
Byly diskutovány další alternativy; opět se objevil starý nápad označit některé sledovací body jako stabilní. Frank Eigler navrhl vytvoření modulu pro kompatibilitu, který by se mohl připojit ke sledovacím bodům, které se změnily, a přemapovat jejich data pro uživatelský prostor do staršího formátu. Také se mluvilo o vytvoření mapovací vrstvy v uživatelském prostoru. Žádný z těchto nápadů se ale v hlavní řadě jádra neobjevil.
Tento problém rozhodně nezmizí; může se jenom zhoršit s tím, jak vývojáři aplikací začnou používat sledovací body, které se do jádra přidávají. Zdá se to jaké zjevné téma k prodiskutování na Jaderném summitu 2010, který je naplánován na začátek listopadu. Těžko předvídat, jaké závěry by z této diskuze mohly vzejít, ale se štěstím o této záležitosti bude přinejmenším jasno.
napsal Jonathan Corbet, 4. října 2010
Za posledních několik let je jasné, že nejtíživější problémy se škálovatelností, kterým Linux čelí, jsou zapříčiněny úložištmi bez rotujících částí (SSD). Narůstající výkonnost, kterou tato zařízení nabízí, nemůže jinak než odhalit úzká hrdla, která mají bloková vrstva a vrstva souborových systémů. Čas od času nicméně není tak jasné, co s tímto problémem budeme dělat. Ve své přednášce na LinuxCon Japan správce blokové vrstvy Jens Axboe popsal práci, která by měla zlepšit škálovatelnost blokové vrstvy, a nabídl pohled na to, kam by se věci mohly ubírat do budoucna.
I když se zátěže různí, většina vzorů I/O obsahuje náhodné a relativně malé požadavky. Dosáhnout nejlepších výsledků tedy vyžaduje schopnost provést velký počet I/O operací za sekundu (IOPS). I nejlepší rotující disky (s 15 000 RPM) mají maximálně cca 500 IOPS; většina disků ze skutečného světa má samozřejmě menší výkonnost a pomalejší I/O.
SSD, které eliminují pohyb hlavičkami a zpoždění způsobená rotací, všechno mění; během krátké doby jsme se dostali ze stovek IOPS na stovky tisíc IOPS. Mnoho lidí řeklo, že tento masivní nárůst počtu operací za sekundu vynutí, aby se bloková vrstva začala podobat síťové vrstvě, kde se postupem času odstraňuje každý možný kousek režie spojené s každým jednotlivým paketem. Jak ale podotkl Jens, času na to není mnoho; síťové technologie se vyvíjely od 10MB/s z roku 1980 na dnešních 10Gb/s, což je v podstatě 30 let. ![[Jens Axboe]](http://www.lwn.net/images/conf/2010/LC-Tokyo/JensAxboe2-sm.jpg)
SSD vynucují podobný skok (o tři řády výše) během mnohem kratší doby - a všechno naznačuje, že zařízení s miliony IOPS nejsou daleko. Výsledek je, jak řekl Jens, „velký problém“.
Tento problém na nás vyskakuje na mnoha místech, ale obvykle se v základu týká soupeření o sdílené zdroje. Režie spojená se zamykáním, která je při 500 IOPS tolerovatelná, je při 500 000 IOPS zničující. Problémy jsou i se soupeřením na úrovni hardwaru – výrobce řadičů příchod SSD zaskočil a ti nyní musí dělat všechno možné, aby dostali výkonnost na požadovanou úroveň. Nárůst počtu vícejádrových systémů věci přirozeně zhoršuje; takové systémy mohou vytvářet problémy se soupeřením kdekoliv v jádře a bloková vrstva není výjimkou. Velká část z nezbytné práce se tedy týká vyhýbání se soupeření.
Předtím bylo nicméně nutné odvést nějakou práci jenom kvůli tomu, aby bloková vrstva poznala, že pracuje s SSD a reagovala podle toho. Tradičně se bloková vrstva řídí tím, že se má vyhýbat pohybu hlaviček; vyhnout se jedinému pohybu může ospravedlnit i poměrně velkou spotřebu času CPU. SSD – alespoň ty dobré – nemusí skoky adres zajímat, takže spotřebovat čas CPU na to se jim vyhnout již nedává smysl. V hardwaru je mnoho způsobů, jakým detekovat SSD disk, ale ty ne vždy fugují – obzvláště u méně kvalitních zařízení. Bloková vrstva tedy v
/sys/block/<zařízení>/queue/rotational
exportuje příznak, kterým lze přenastavit pohled systému na to, s jakým zařízením pracuje.
Zlepšení výkonnosti SSD může být výzvou. Není jediné úzké hrdlo, které by způsobovalo problémy s výkonností; naopak je potřeba opravit mnoho malých věcí. Každá oprava představuje malý pokrok, ale většinou slouží jenom k odhalení dalšího problému. Navíc je testování výkonnosti složité; výsledky často nelze reprodukovat a zcela je rozhodí i malé změny. To platí obzvláště pro větší systémy s více CPU. Do vygenerování konzistentních výsledků se také často zaplete správa napájení.
Jedna z prvních věcí, kterou bylo potřeba u SSD disků vyřešit, je zapojování fronty [queue plugging]. Na rotujícím disku první požadavek na I/O operaci, který se objeví ve frontě, způsobí, že se fronta „zapojí“, což znamená, že se žádné operace k hardwaru nevyšlou. Smyslem tohoto zapojování je, že se tím ponechá víc času na to, aby dorazily další I/O požadavky; bloková vrstva je pak schopna sousedící požadavky sloučit (což omezuje počet operací) a seřadit je do optimálního pořadí, což zvyšuje výkonnost. SSD disky většinou z tohoto chování neprofitují, i když slučování požadavků stále nějakou hodnotu má. Vyhození (nebo přinejmenším omezení) zapojování nejenom že odstraňuje zbytečné zpoždění, ale také to omezuje potřebu zabrat zámek fronty.
Pak je zde významná záležitost časových limitů požadavků. Jako většina I/O kódu i bloková vrstva si musí všimnout, že zařízení I/O požadavek nikdy nedokončilo. Tuto detekci zajišťují časové limity. Stará implementace zahrnovala pro každý běžící požadavek jeden časový limit, ale to zjevně nebude škálovat moc dobře, když počet požadavků bude obrovský. Řešením bylo použít časovač pro frontu, který významně omezil počet současně běžících časovačů.
Blokové I/O operace, díky jejich z principu nepredikovatelným dobám vykonávání, tradičně přispívají entropií do jaderné zásoby náhodných čísel. To má ale problém; nutné volání add_timer_randomness() musí zabrat globální zámek, což způsobuje nepříjemné celosystémové soupeření. Byla odvedena nějaká práce na tom, aby se tato volání shromažďovala do větších skupin a náhodná čísla se hromadila na jednotlivých CPU samostatně, ale i s dávkami po 4k operacích byly výkonnostní dopady významné. Krom toho není moc jasné, jestli dává smysl používat SSD jako zdroj entropie - SSD nemají pohybující se mechanické části, takže časy dokončení operací lze předvídat mnohem lépe. V současnosti nicméně SSD do zásoby náhodných čísel přispívají; administrátoři, kteří by toto chování chtěli změnit, tak mohou udělat změnou proměnné queue/add_random v sysfs.
Je potřeba vyřešit i další záležitosti ohledně zamykání. Postupem času bloková vrstva přestala být chráněna velkým jaderným zámkem a místo toho byla chráněna na úrovni blokového zařízení; pak na úrovni disků. Soupeření zámků je ale i tak stále velkým problémem. I/O plánovač dodává další soupeření sám o sobě, obzvláště pokud provádí účetní operace na úrovni disků. Zajímavé je, že zde obvykle není problémem soupeření o zámky jako takové; zámky nejsou drženy příliš dlouho. Velký problém je poskakování dat mezi řádky v cachích způsobené stěhováním zámků mezi procesory. Tradiční technika uvolnění a opětovného zabrání zámku zde nepomáhá - naopak věci zhoršuje. Je tedy potřeba vyhnout se zamykání úplně.
Požadavky pro blokovou vrstvu vstupují do systému pomocí __make_request(), která zodpovídá za to, že se požadavek (reprezentovaný strukturou BIO) dostane do fronty. K tomu je potřeba zabrat dva zámky – tři, pokud se používá I/O plánovač CFQ. Dva tyto zabrané zámky jsou důsledkem rozdělení jednoho zámku, což mělo v minulosti omezit soupeření; toto rozdělení věci zhoršuje, když systém řeší požadavky při rychlostech SSD. Zrušení tohoto dělení vedlo přibližně k 3% nárůstu IOPS a omezení času CPU na 32 jádrovém systému. Jak Jens řekl, je to „rychlý hack“, ale demonstruje ten druh změn, který je zde zapotřebí.
Dalším krokem je zahození alokace I/O požadavků v dávkách – to je mechanismus, který umožňuje zvýšit propustnost na rotujících discích tím, že umožní zaslat několik požadavků naráz. Jens také plánuje zahodit kód čítající alokace, který sleduje počet běžících požadavků v daném okamžiku. Čítání běžících I/O operací vyžaduje globální čítače a s tím spojené soupeření, ale ve většině případů se bez něj lze obejít. Na úrovni fronty požadavků k nějakému čítání docházet bude, aby nad počtem běžících operací zůstala nějaká kontrola. Krom toho je zde nějaké čítání na úrovni jednotlivých požadavků, které lze pročistit; Jens si myslí, že dokončení požadavku by bylo možné provést zcela bez zamykání. Doufá, že tato práce bude připravena k začlenění do 2.6.38.
Další důležitá technika pro omezení soupeření je udržet práci na jednom CPU tak často, jak to jenom půjde. Konkrétně má velké náklady stav, když dokončení požadavku řeší jiné CPU, než které požadavek zadalo. V takové situaci zámky nepříjemně poskakují mezi CPU a slab alokátor nereaguje příliš dobře, když je paměť alokovaná jedním procesorem uvolněna jinde. V síťové vrstvě je tento problém řešen technikami jako směrování přijímaných paketů, ale na rozdíl od některého síťového hardware řadiče pro blokové I/O nejsou schopny mířit specifické požadavky na přerušení informující o specifickém I/O na specifické CPU. Bylo tedy zapotřebí jiné řešení.
Řešení má podobu funkce smp_call_function(), která provádí rychlá volání mezi CPU. Pomocí smp_call_function() může kód dokončení blokového I/O požadavku namířit dokončení specifického požadavku na CPU, které daný požadavek původně vyslalo. Výsledkem je relativně jednoduché zlepšení výkonnosti. Odhodlaný administrátor, který chce systém ladit manuálně, může dosáhnout lepších výsledků, ale to znamená spoustu práce a řešení bývá křehké. Tento kód – který byl začleněn do 2.6.27 a jako výchozí nastaven v 2.6.32 – je jednoduchým způsobem, jak odstranit velkou část soupeření mezi CPU. Jens s pýchou poznamenal, že bloková vrstva nenásledovala kód síťování, co se týče směřování dokončování – měla ho první.
Na druhou stranu kód pro omezení přerušení blk-iopoll se síťovou vrstvou nejenom inspiroval – některé jeho části odtud byly „beze studu vykradeny“. Kód blk-iopoll vypíná přerušení spojené s dokončením požadavku, když je velký I/O provoz; v takovém případě používá k vyzvednutí dokončených požadavků dotazování. Na testovacím systému tento kód snížil počet přerušení z 20 000 za sekundu na cca 1000. Jens nicméně říká, že výsledky na skutečně používaných systémech jsou o něco méně jasné.
Přístup, který „má větší zásluhy“ je „připojování kontextu“, což je přepracování kódu pro připojování fronty. V současnosti se připojování fronty řeší implicitně při zadání I/O požadavku, přičemž později je nutné explicitní odpojení. To bylo zdrojem mnoha chyb; poměrně často se na odpojení fronty zapomnělo. V plánu je zajistit, aby připojování a odpojování bylo plně implicitní, ale zároveň těm, kdo předávají I/O, umožnit informovat blokovou vrstvu, že brzy přijdou další požadavky. Díky tomu je kód čistší a robustnější; také se tím odstraňuje spousta drahých stavů front, které je potřeba udržovat. Ještě je potřeba vyřešit nějaké problémy, ale kód funguje, „je chutný v mnoha ohledech“ a celkem zmizí nějakých 600 řádek kódu. Začlenění očekávejme v 2.6.38 nebo 2.6.39.
Nakonec je tu „podivné teritorium“ vícefrontové blokové vrstvy – což je nápad, který také vzešel ze síťové vrstvy. Vytvoření vícenásobných I/O front pro dané zařízení umožní více procesorům řešit I/O požadavky simultánně s menším soupeřením. V současnosti je to nicméně těžké, protože řadiče blokového I/O (ještě) nemají podporu pro více front. Tento problém bude dříve či později opraven, ale i tak bude několik dalších problémů, které bude potřeba překonat: I/O bariéry budou významně komplikovanější, totéž platí pro účtování pro jednotlivá zařízení. Bude to tedy vyžadovat nějaké významné změny a speciální I/O plánovač. Jens nenaznačil, kdy by mohl být tento kód začleněn.
Závěrem této přednášky je, že linuxová bloková vrstva řeší významné záležitosti vynucené změnami hardwaru. Na jejich vyřešení se ale pracuje a kód se mění tím směrem, který je potřeba. V době, kdy si většina z nás bude moci dovolit systém s jedním z těch masivních polí s 1 MIOPS, by Linux měl být schopen využít jejich potenciál.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
25.10.2010 13:26
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
V době, kdy si většina z nás bude moci dovolit systém s jedním z těch masivních polí s 1 MIOPS, by Linux měl být schopen využít jejich potenciál.je systém který by to dokázal už dnes? co windows jsou napřed nebo pozadu ( co se ssd disků týká ) za linuxem?
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz