Jaderné noviny - 14. 5. 2008

1. 7. 2008 | Jirka Bourek | Jaderné noviny | 3508×

Aktuální verze jádra: 2.6.26-rc2. Citáty týdne: Ingo Molnár, Andrea Arcangeli, Andres 'dilinger' Salomon. Velký jaderný zámek opět udeřil. Učíme se zacházet s cachováním. Rozšiřování systémových volání.

Obsah

• Aktuální verze jádra: 2.6.26-rc2
• Citáty týdne: Ingo Molnár, Andrea Arcangeli, Andres 'dilinger' Salomon
• Velký jaderný zámek opět udeřil
• Učíme se zacházet s cachováním
• Rozšiřování systémových volání

Aktuální verze jádra: 2.6.26-rc2

Současná předverze jádra 2.6 je 2.6.26-rc2 vydaná 12. května. Toto vydání obsahuje převážně opravy chyb, ale také mění velký jaderný zámek [big kernel lock] (zpět) na spinlock; více informací vizte ve článku níže.

Současná verze -mm stromu je 2.6.26-rc2-mm1. Nedávné změny v -mm zahrnují změnu základního bodu podle stromu linux-next, framework ladění inicializace paměti, odstranění portu v850, novou sadu systémových volání s přidanými argumenty pro příznaky (vizte níže), makro WARN(), které bere argumenty ve stylu printk(), online defragmentace ext4, podporu ext4 FIEMAP a souborový systém OMFS.

Současná verze stabilního jádra je 2.6.25.3 vydaná 9. května. Tato verze byla vydána dřív, než se plánovalo, protože zahrnovala několik bezpečnostních oprav.

V době psaní tohoto článku je aktualizace 2.6.25.4 - obsahující několik tuctů oprav - v procesu revize.

Citáty týdne: Ingo Molnár, Andrea Arcangeli, Andres 'dilinger' Salomon

Podle mé rychlé analýzy git-log při současném tempu odstraňování velkého jaderného zámku budeme muset čekat více než 10 let, než z jádra odstraníme většinu BKL kritických sekcí a opět dostaneme akceptovatelné latence.

-- Ingo Molnár nechce čekat tak dlouho

I kdybys měl naprostou pravdu, s Nickovými mmu notifikátory, Rustyho mmu notifikátory, mými původními mmu notifikátory, Christophovou EMM verzí mých nových mmu notifikátorů, s mými nejnovějšími mmu notifikátory a lidmi, kteří dávají návrhy, testují kód a nutně ho potřebují, s dalšími patchi, které v této oblasti čekají na začlenění do 2.6.27, musí být každému jasné, že šance, že se tento kód nevyvine k dokonalosti, je nulová, ale předtím, než ho začneme používat, nemůžeme čekat, až bude dokonalý, protože jinak jsme v háji.

-- Andrea Arcangeli - také netrpělivý

19:29 * dilinger posílá svůj patch do lkml do správně plamenné diskuze

19:32 Quozl> dilinger: to se jmenuje "kalení patche"? ;-} díky horku z plamenů té diskuze ten patch víc vydrží

-- Andres 'dilinger' Salomon

Velký jaderný zámek opět udeřil

Když Alan Cox poprvé zajistil fungování Linuxu na víceprocesorových strojích, přidal primitivum nazvané velký jaderný zámek [Big Kernel Lock, BKL]. Původně tento zámek zajistil, že pouze jeden procesor může v daný čas zpracovávat jaderný kód. Během let se role BKL postupně zmenšovala s tím, jak bylo v jádře implementováno jemnější zamykání společně s bezzámkovými algoritmy. Úplné zbavení se BKL bylo v seznamu věcí, které je potřeba udělat, už nějaký čas, ale pokrok v tomto směru byl v uplynulých letech pomalý. Nedávná výkonnostní regrese spojená s BKL mohla tomuto úkolu přidat na důležitosti; také ukázala, že jemné algoritmické změny mohou způsobit velký rozdíl.

AIM benchmark se pokouší měřit propustnost systému spuštěním velkého počtu úloh (v řádu tisíců), každá z nich běží v části jádra. Yanmin Zhang ohlásil, že jeho výsledky se s jádrem 2.6.26-rc1 zhoršily o přibližně 40 %. Dal si práci a problém dělil půlením; jako viník se ukázal kód obecných semaforů. Odstranění patche odstranilo i regresi, ale za cenu navrácení 7000 řádek starého kódu, který nikomu nechyběl. Myšlenka na návrat předchozí implementace semaforů inspirovala několik lidí, aby se na problém podívali více zblízka.

Netrvalo dlouho zúžit pohled na BKL, který byl před pár lety konvertován na semafor. Část tohoto procesu byla jednoduchá - v jádře už moc dalších semaforů nezbývá, zvlášť ne na místech kritických pro výkonnost. Nicméně BKL tvrdohlavě zůstává v řadě vnitřních míst, včetně systémového volání fcntl(), mnoha implementací ioctl(), TTY kódu a open() pro znaková zařízení. To je dost na to, aby špatně se chovající BKL vytvořil větší problémy, obzvlášť když běží na VFS náročné benchmarky se značným soupeřením.

Ingo Molnár problém vystopoval v novém kódu semaforů. Ve zkratce: nový kód byl příliš férový. Když je semafor uvolněn a čeká na něj další vlákno, semafor je předán tomuto novému vláknu (které je v tu chvíli nastaveno jako spustitelné). Tento přístup zajišťuje, že vlákna získají semafor v pořadí přibližně takovém, v jakém si o něj požádaly.

Problém je v tom, že férovost může být drahá. Vlákno, které čeká na semafor, může být na jiném procesoru, může mít studenou cache a může mít nízkou prioritu, takže třeba nějaký čas ani nemusí běžet. Mezitím může semafor požadovat jiné vlákno, ale to se dostane na konec fronty za nového vlastníka, který možná stále ještě neběží. Výsledkem je určité množství mrtvého času, kdy semafor nedrží žádné běžící vlákno. A Yanminova zkušenost s AIM benchmarkem to ukázala: systém běžel 50 % času bez zátěže.

Řešením je použití techniky ze staršího kódu semaforů: kradení zámků. Jestliže vlákno zkusí získat semafor a tento semafor je k dispozici, toto vlákno ho dostane bez ohledu na to, jestli nějaké další vlákno trpělivě čeká ve frontě. Jinak řečeno, vlákno na začátku fronty dostane semafor, až když se rozběhne a skutečně ho zabere; jestliže je příliš pomalé, někdo to stihne před ním. V mezilidských vztazích je tento druh chování považován za nezdvořilost (alespoň v některých kulturách), přesto je všem znám. V multiprocesorovém počítači ale znamená rozdíl mezi akceptovatelnou a neakceptovatelnou výkonností - dokonce i vlákno, kterému je zámek ukraden, na tom v dlouhodobé perspektivě vydělá.

Je zajímavé, že patch, který tuto změnu implementuje, byl začleněn do hlavní řady a pak odstraněn před tím, než vyšlo 2.6.26-rc2. Původním důvodem bylo, že patch rozbil semafory v jiných situacích; v některých vzorcích použití mohl kód semaforu selhat při probouzení vlákna, když semafor přešel do stavu "k dispozici". Tato chyba mohla být určitě opravena, ale zdá se, že takto to nepůjde - děje se tu toho o něco víc.

Místo toho Linus začlenil patch, který jednoduše mění BKL na spinlock. Kompletním vyzkratováním kódu semaforů patch opravuje AIM regresi a nechává na místě pomalý (ale férový) kód semaforů. Tato změna také mění BKL na nepreemptivní, což není tak úplně dobrá zpráva pro ty, kdo se zabývají problémy s latencí - obzvlášť pro lidi z realtime stromu.

Odůvodnění tohoto postupu se zdá být následující: jak semafory, tak BKL jsou staré a k používání nedoporučené [deprecated] mechanismy, jejichž použití má být minimalizováno (semafory) nebo mají být v blízké budoucnosti úplně odstraněny (BKL). Vzhledem k tomu nemá cenu přidávat do kódu semaforů větší komplexitu, když byl kód v 2.6.26 dramaticky zjednodušen. A zdá se, že Linus je se suboptimálním BKL spokojen:

Upřímně řečeno, možná potřebujeme špatný BKL, abychom tyhle chyby vůbec opravili. Bylo to tak, že lidé pracovali na tom, aby se BKL choval lépe, a selhali. Místo trávení času snahou, aby fungoval lépe (za strašlivou cenu), proč raději neříct "Ani omylem - když jsou s BKL problémy, místo poskakování kolem něj je potřeba s lidmi spolupracovat na tom, abychom se ho zbavili."

Výsledkem toho všeho může nakonec být znovuoživená snaha odstranit velký jaderný zámek z jádra. Stále to není něco, co by se mohlo stát během několika vydání jádra: je spousta kódu, který může nenápadně záviset na sémantice BKL a není způsob, jak se bez detailního auditu ujistit, že odstranění bude bezpečné. A není to malý úkol, Alan Cox přepracovává TTY kód už nějaký čas, ale stále mu zbývají oblasti, které je potřeba pokrýt. TTY kód je přitom jenom část problému, takže BKL si tu s námi ještě nějaký čas pobude.

Učíme se zacházet s cachováním

Změny ve správě paměti (v architektuře x86) způsobily několika jaderným vývojářům překvapení. Když byly tyto problémy řešeny, ukázalo se, že ne všichni rozumí tomu, jak funguje cachování na současných systémech. Arjan van de Ven sepsal pár poznámek a poslal je Jonathanu Corbetovi ve snaze udělat v té oblasti jasno. Tyto poznámky jsou zapracovány v tomto článku, autor děkuje Arjanovi za jejich shromáždění - všechny užitečné věci níže jsou od něj.

Jak se měli dozvědět všichni čtenáři Co by měl každý programátor vědět o paměti, cachovací mechanismy používané současnými procesory jsou pro výkon systému kritické. Paměť je pomalá; bez cache by systémy běžely mnohem pomaleji. Jsou ale situace, ve kterých je cachování nepřípustné, takže hardware musí poskytnout mechanismy, které nad ním umožní převzít ve specifické oblasti paměti kontrolu. S 2.6.26 Linux (poněkud opožděně) začíná dohánět současný stav hardwaru x86; to přináší nějaké změny ohledně toho, jak je spravováno cachování.

Je dobré začít definicí pojmů, které se budou používat. Jestliže je kus paměti cachovatelný, znamená to:

• Procesoru je dovoleno kdykoliv načíst tuto paměť do cache. Může to udělat bez ohledu na to, jestli má běžící program zájem na čtení této paměti. Čtení cachovatelné paměti může nastat jako důsledek spekulativního vykonávání, explicitního přednačítání [prefetch] nebo z mnoha jiných důvodů. CPU potom může držet obsah této paměti ve své cache tak dlouho, jak chce, podléhá přitom pouze explicitnímu požadavku uvolnit daný řádek z cache, který přijde odněkud ze systému.

• Procesoru je povoleno v libovolný čas zapsat obsah své cache do paměti, opět bez ohledu na to, co chce dělat běžící program. Paměť, která nebyla změněna programem, může být znovu zapsána, zápisy provedené programem mohou být drženy v cache po nestanovenou dobu. CPU nepotřebuje mít načtenou celou řádku cache před jejím zpětným zapsáním.

Tohle všechno znamená, že pokud procesor vidí oblast paměti jako cachovatelnou, musí být možné (téměř) zcela oddělit práci s hardwarem od toho, co si program myslí, že dělá. Cachovatelná paměť musí být vždy čitelná bez vedlejších efektů. Zápisy musí být idempotentní (zapsání jedné hodnoty na stejné místo několikrát musí mít stejný efekt jako zapsání této hodnoty jednou), nezávislé na řazení a nezávislé na velikosti. Nesmí existovat žádný vedlejší efekt zpětného zápisu hodnoty, která byla z daného místa načtena. Prakticky to znamená, že to, co sedí v cachovatelném rozsahu paměti, musí být normální paměť - i když jsou i další případy.

Pokud je rozsah paměti necachovatelný, každé čtení a každý zápis generovaný softwarem je předáván přímo dotčenému zařízení a cache CPU se obcházejí. Jedna výjimka je zápis do I/O paměti PCI sběrnice; v tomto případě je PCI hardwaru dovoleno ukládat zápisové operace do vyrovnávací paměti a kombinovat je. Záměna zápisových a čtecích operací ale možná není, což je důvod, proč je čtení z I/O paměti často ovladači používáno jako určitá zápisová bariéra pro PCI zařízení.

Variantou necachovaného přístupu je kombinování zápisu [write combining]. Pro čtecí operace je paměť s kombinovaným zápisem totéž, jako necachovatelná paměť. Hardwaru je nicméně povoleno ukládat po sobě jdoucí zápisové operace do zásobníku a vykonat je jako menší sérii větších I/O operací. Hlavním uživatelem tohoto režimu je video paměť, u které se často používají sekvenční zápisy a která nabízí významné zlepšení výkonu, když jsou tyto zápisy zkombinovány.

Důležité je použít pro každý rozsah paměti správný režim cache. Pokud není běžná paměť nastavena jako cachovatelná, povede to k otřesné výkonnosti. Povolení cachování I/O paměti může způsobit podivné chování hardwaru, poškození paměti a pravděpodobně je příčinou globálního oteplování. Proto se CPU a hardware skrývající se za danou adresou musí o cachování shodnout.

Tradičně bylo cachování ovládáno vlastností CPU zvanou "registry pro typ rozsahu paměti" [memory type range registers, MTRR]. Každý procesor má konečnou sadu MTRR, každý z nich řídí rozsah fyzického adresovatelného prostoru. BIOS nastaví některé MTRR před bootem operačního systému; některé další jsou později k dispozici k dalšímu ladění. MTRR jsou ale poněkud neflexibilní, závisí na tom, že BIOS není zachybovaný, a jsou omezené, co se počtu týče.

V nedávnější době výrobci CPU přidali koncept známý jako "tabulky atributů stránek" [page attribute tables, PAT]. PAT je v podstatě sada bitů uložená v záznamu tabulky stránek, která řídí, jak CPU cachuje každou stránku. PAT bity jsou flexibilnější a díky tomu, že žijí v záznamech tabulky stránky, vypotřebovat se dají jenom obtížně. Také jsou zcela pod kontrolou operačního systému a ne BIOSu. Jediný problém je, že Linux na architektuře x86 PAT nepodporuje, a to přesto, že hardware tuto schopnost má již pár let.

Chybějící podpora pro PAT je důsledkem několika věcí, z nichž problematická podpora na straně hardwaru nebyla nevýznamná. Procesory se ale během let stabilizovaly do stavu, ve kterém je možné vytvořit rozumný whitelist rodin CPU, o kterých se ví, že s PAT opravdu fungují. Také se objevily potíže na straně jádra; když několik záznamů v tabulce stránek odkazuje na stejnou fyzickou stránku (běžný jev), všechny záznamy v tabulce stránek musí používat stejný režim cache. I krátké okno s nekonzistentním cachováním může systém shodit. Kód na straně jádra byl ale vyspraven a výsledkem je, že podpora pro PAT byla začleněna do jádra 2.6.26. Autor článku ho píše na stroji, kde je PAT zapnuté bez negativních jevů - zatím.

Na většině systémů BIOS nastavuje MTRR tak, že běžná paměť je cachovatelná a I/O paměť ne. Procesor potom může situaci komplikovat PAT bity. Obecně, když se objeví konflikt mezi nastavením MTRR a PAT, vítězí to nastavení, které nastavuje nižší úroveň cachování. Zdá se, že jediná výjimka je, když jedno říká "necachovatelné" a druhá povoluje kombinování zápisu; v tomto případě se použije kombinování zápisu. CPU tedy může díky správě PAT bitů provést několik efektivních změn:

• Necachovatelná paměť může mít zapnuté kombinování zápisu. Jak bylo zmíněno výše, tento režim je nejužitečnější u video paměti.

• Běžná paměť se dá nastavit jako necachovatelná. Tento režim může být také užitečný pro video paměť; v tomto případě je příslušná paměť obyčejná RAM, ke které přistupuje i video karta.

Linuxové ovladače zařízení musí mapovat I/O paměť předtím, než k ní přistoupí; funkce, která to vyřídí, je ioremap(). ioremap() dříve nijak neměnila cachovatelnost mapovaného rozsahu; prostě ho vzala tak, jak ho nastavil BIOS. Prakticky to znamenalo, že I/O paměť bude necachovatelná, což bylo téměř vždy to, co ovladač chtěl. Existuje oddělená varianta ioremap_nocache() pro případy, kdy chce být autor explicitní, ale užití tohoto rozhraní bylo vždy vzácné.

V 2.6.26 bylo rozhraní ioremap() změněno a paměť pokaždé mapuje jako necachovatelnou. To vedlo k několika překvapením v případech kde, jak se to stává, byl rozsah dané paměti cachovatelný a to bylo to, co kód potřeboval. Od 2.6.26 tento kód nebude fungovat, dokud volání nebude změněno, aby používalo nové rozhraní ioremap_cache(). Také je k dispozici funkce ioremap_wc pro případy, že je potřeba mapování s kombinováním zápisu.

Je také možné manipulovat s PAT záznamy adresového rozsahu explicitně:

int set_memory_uc(unsigned long addr, int numpages);
int set_memory_wc(unsigned long addr, int numpages);
int set_memory_wb(unsigned long addr, int numpages);

Tyto funkce nastaví dané stránky jako necachovatelné, s kombinovaným zápisem nebo zpětným zápisem (cachovatelné) v uvedeném pořadí. Je zbytečné říkat, že kdokoliv bude tyto funkce používat, by měl mít zcela jasno v tom, co dělá, jinak jsou nepříjemné důsledky naprosto jisté.

Rozšiřování systémových volání

Udělat rozhraní dobře je těžký, ale nutný úkol, obzvlášť když má být toto rozhraní podporováno "navždy". Příkladem je rozhraní pro systémová volání, které jádro dává k dispozici uživatelskému prostoru, takže přidávání vlastností musí být prováděno velmi pečlivě. I tak, když Ulrich Drepper začal pracovat na odstranění díry, která by mohla vést k souběhu [race condition], pravděpodobně neočekával všechny různé cesty, které bude muset zkusit, než se dostane k přijatelnému řešení.

Problém pramení z požadavku na schopnost vytvářet popisovače souborů [file descriptors] s novými vlastnostmi - jako jsou popisovače zavřít-při-spuštění [close-on-exec], neblokující [non-blocking] nebo nesekvenční [non-sequential]. Tyto vlastnosti nebyly vzaty do úvahy, když bylo vyvinuto rozhraní systémového volání. Koneckonců, mnoho z těchto systémových volání se v podstatě neměnilo od doby prvních implementací Unixu ze 70. let. Volání open() je nejzjevnější způsob, jak jádro žádat o popisovač souboru, ale je mnoho dalších.

Ve skutečnosti je open() nejsnáze rozšiřitelné novými vlastnostmi, protože má argument flags (příznaky). Volání jako pipe(), socket(), accept(), epoll_create() a další také vytvoří popisovač souboru, ale argument flags nemají. Kvůli podpoře přídavných vlastností popisovačů pocházejících z těchto volání by muselo být přidáno něco jiného.

Funkce zavřít-při-spuštění je obzvlášť důležitá pro uzavření bezpečnostní díry ve vícevláknových programech. V současnosti mohou programy použít fcntl() a změnit popisovač tak, aby měl vlastnost zavřít-při-spuštění, ale vždy tam je časové okno mezi vytvořením popisovače a změnou jeho chování. Jiné vlákno v tomto okně může zavolat exec(), čímž potenciálně citlivý popisovač prosákne do nově spuštěného programu. Uzavření tohoto okna vyžaduje řešení v jádře.

V červnu minulého roku po několika chybných začátcích Linus Torvalds navrhl přidat systémové volání indirect() a předávat jím příznaky systémovým voláním, která je v současnosti nepoužívají. To by současným voláním umožnilo zůstat beze změny a pouze nová by používala indirect(). Programy v uživatelském prostoru by pravděpodobně tuto funkci nevyužívaly přímo, ale místo toho by volaly funkce glibc, které by se o nutná volání indirect() postaraly.

Davide Libenzi vytvořil sys_indirect() patch v červenci, ale Ulrich prohlásil, že je "komplexnější, než bylo ujednáno." Proto vytvořil svou vlastní "triviální" implementaci, kterou popsal na svých stránkách v listopadu. Na linux-kernel se setkal s méně než nadšenou reakcí za to, že toto rozhraní bylo - mimo jiné - extrémně ošklivé.

Alternativou k sys_indirect() je vytvořit nové systémové volání pro každé existující volání, které potřebuje argument příznaků. Někteří, včetně Linuse, to považovali za komplikované řešení, což vedlo hackery jádra k hledání alternativ. Nepřímý přístup měl také některé potenciální výhody, protože byl považován za něco, co by mohly použít syslety a umožnit tak asynchronní systémová volání. Nezdálo se, že dojde k nějakému rozhodnutí, takže Ulrich Linuse o nějaké požádal:

Mohl bys prosím rozhodnout ohledně sys_indirect? Jiný návrh nebyl, takže alternativou je přidat více systémových volání.

Aby podpořil svoji argumentaci, že sys_indirect() je ta správná cesta, vytvořil Ulrich také patch, který přidává některá z potřebných systémových volání. Začal s rodinou socket() tím, že přidal socket4(), socketpair5() a accpet4() - přidal počet argumentů ke jménu funkce jako v wait3() a wait4(). Výběrem právě těchto volání si Ulrich možná příliš nepomohl, protože jak okamžitě poznamenal Alan Cox, argument type lze přetížit:

Vzhledem k tomu, že nikdy nebudeme mít 2^32 typů socketů a v jistém smyslu jde o část typu, proč rovnou nepoužít

socket(PF_INET, SOCK_STREAM|SOCK_CLOEXEC, ...)

což by bylo mnohem čistší a na straně socketů by nebyla potřeba žádná nová volání.

Michael Kerrisk prohlédl sadu systémových volání, která generují popisovače, a kategorizoval je podle toho, jestli potřebují přidat příznak flag. Zjistil, že přibližně polovina volání, která produkuje popisovače, se změnit nepotřebuje, protože buď může použít přetěžovací trik jako volání socket, nebo glibc API již přidalo argument příznaků, nebo existují alternativy, které poskytují stejnou funkci jako příznaky.

Jako odpověď Ulrich podnikl poslední pokus protlačit nepřímý přístup a řekl:

Nebo prostě přidáme sys_indirect (které se také dá použít k rozšíření dalších systémových volání (nejenom pro záležitosti okolo CLOEXEC) a necháme uživatelskou úroveň (tj. mě), aby se postarala o přidání nových rozhraní do libc. Jak můžete vidět, v aktuálnějších rozhraních jako signalfd jsem již přidal parametr, takže počet změn v rozhraní by byl nižší.

I když má nepřímý přístup několik výhod, Linusovi se líbil přístup, který navrhoval Alan Cox, a řekl:

Ok, musím přiznat, že se mi velmi líbí. Vypadá to mnohem čistěji, ale co je možná důležitější, také to vypadá čitelnější a jednodušeji použitelné pro programátory v uživatelském prostoru.

Vývojáři budou nakonec používat jen ta nová rozhraní, u kterých budou moci snadno testovat existenci nového kódu. Linus dal příklad, jak se to dá udělat použitím příznaku NOATIME u open(), který je přítomen až od 2.6.8. Je to právě ta záležitost testovatelnosti, díky které věří, že přístup založený na příznacích je ten správný:

A to je problém s čímkoliv, co není založené na příznacích. Jakmile přidáš nové systémové volání, začne být dost nepěkné dělat to, co je popisováno výše. Jak staticky otestuješ, že máš systémové volání? A teď potřebuješ přidat celou záležitost do autoconf, abys zjistil, jestli existuje, a když ano, musíš také otestovat, jestli funguje. A dokonce to nemůžeš ani udělat pomalou cestou [slow-path], jak je uvedeno výše (kde se selhání bez příznaku změní na rychlou cestu [fast-path]).

Ulrich se nyní snaží o tento nový přístup se zmenšeným počtem nových systémových volání místo přidání všeobecného rozšiřovacího mechanismu systémových volání, jako je sys_inidirect(). Ve vysvětlujícím patchi na začátku série píše, která systémová volání budou potřebovat nové rozhraní pro uživatelský prostor: paccept, epoll_create2, dup3, pipe2 a inotify_init1() a která ho potřebovat nebudou: signalfd4, eventfd2, timerfd_create, socket a socketpair.

Ulrich vytvořil několik iterací patchů, které reagují na největší obavy vyjádřené vývojáři jádra během tohoto procesu. Objevilo se několik problémů specifických pro architektury, ale Ulrich zlikvidoval i ty. Jestliže se neobjeví další překážky na cestě, zdá se to být pravděpodobný kandidát pro začlenění do 2.6.27.

       

Komentáře

[Jardík]

LOL, štítky: aktualizace, algoritmy, bad os, BIOS, CPU, diskuze, ext4, fet, framework, fucked OS, glibc, haluz, hardware, houbičky, kernel, Linux, minority OS, multimédia, nepoužitelný os, not working os, opravy, ovladače, pat, patch, PCI, piece of crap, procesory, programování, RAM, sběrnice, souborové systémy, špatný os, unstable OS, unusable os, VFS, video, výjeb

PS: Ikdyž si budete myslet, že jsem to byl já, já to nebyl! Já bych se k tomu přiznal. Mám smíšenou poruchu osobnosti schizoidní a dissociální.

[disorder]

hehe, zihanie patchov :)

[peppa]

Žíhání (zahřívání a pomalé ochlazování na vzduchu) je opakem kalení (zahrátí a prudké zchlazení ve vodě).

[cronin]

Principialne je to opak, prakticky je to doplnok. Prvym krokom je vzdy kalenie. Pri tomto sa pouziva ovela vyssia teplota a prudke schladenie. Schladenie vo vode je skor z nudze cnost, lepsie je schladenie do oleja. Schladenie do vody je prudsie, kvoli vyssej tepelnej kapacite vody, vedie k vacsiemu vytvrdeniu, ale aj k ovela krehkejsiemu materialu. Prave na odstranenie krehkosti sa pouziva popustanie (cesky zihanie). Ocel sa po zakaleni opatovne zohreje, ale uz na ovela nizsiu teplotu ako pred kalenim, pricom sa pouzivaju rozne finty "nepriameho ohrevu", kde je to mozne. Potom sa material necha pomaly vychladnut. Opat, ochladenie na vzduchu je z nudze cnost, nakolko ochladenie na vzduchu je relativne rychle. Lepsie je popustanie v popole, kde je vychladnutie ovela pomalsie. Vseobecne vzate, spravne popustanie je ovela vacsie majstrovstvo ako kalenie.

Jaj, ze Linux? Aha.

[Yokotashi]

Pri kaleni do olova netreba popoustet.

Jeste se popousti nejak tak, ze se to zakali do vody (tusim), ale ihned se to vytahne a vnitrnim teplem (zchladilo se to jen na povrchu) se to zahreje a pak vychladne.

[Xerces]

Zihat muzes i bez kaleni. Existuje treba i normalizacni zihani, zihani na snizeni vnitrniho pnuti po ohybani atd.

[xxxs]

nemusi byt len doplnkom. okrem metalurgie sa napr. pouziva v chemii pri analyze a cisteni latok.

[petr_p]

Chápu, že spravovat glibc je občas na mašli, ale Ulrich Drepper by se mohl trochu krotit. Např. tohle je už opravdu na psychiatra.

[mikro]

vdaka za kvalitny preklad aj clanok. velmi zaujimavy diel.

[Jirka]

Radsi bych zmenil rozhrani, to znamena, pridal funkce s parametrem flags. Sice by to znamenalo komplikaci, ale zda se mi to cistejsi a hlavne spolehlivejsi reseni do budoucna nez pretezovani type.