Jaderné noviny 177

8. 8. 2002 | Leoš Literák | Jaderné noviny | 2380×

Gang Scheduling pod Linuxem, diskuse nad datem uvedení řady 2.6, exportovat či neexportovat a vážný problém s IDE ve vývojové řadě.

Do konference přišlo celkem 1424 emailů, nejvíce psali Ingo Molnar, Alan Cox a Robert Love.

Gang Scheduling pod Linuxem, 16 emailů

Někdo se zeptal, zda existuje pod Linuxem podpora pro gang scheduling a pokud ano, jaký je její stav. Ingo Molnar odpověděl:

Ano, synchronní buzení [synchronous wakeup] je určitou formou gang schedulingu. Ve své podstatě používá informaci o komunikaci skutečných procesů k tomu, aby přesunul související úlohy na stejný procesor. Takže protože se jedná o automatickou vlastnost, není třeba nikde deklarovat, které procesy jsou členy stejného gangu. Dalším způsobem, jak dosáhnout stejného efektu, je svázat rodičovský proces s určitým CPU a všichni jeho potomkové budou k tomuto CPU také navázáni.

William Lee Irwin III zaslal odkaz na Přehled Gang Schedulingu ve formátu PDF. Sam Mason napsal: Hlavní použití je u programů, které potřebují velkou výpočetní sílu na určitý problém. Ten je nejdříve rozdělen na malé kousky a každý je zpracován na jiném CPU. Když jsou všechny kousky zpracovány, jsou spojeny dohromady a program pokračuje dále. Slabým místem je, že zpoždění kteréhokoliv kousku zastaví výpočty na ostatních procesorech, které by jinak mohly zpracovávat další várku. Je důležité si uvědomit, že toto není normální metoda schedulování a používá se pouze pro velmi specializovaný software, který má téměř kompletní vládu nad počítačem.

Hubertus Franke z IBM měl s touto vlastností osobní zkušenosti: Pracoval jsem na implementaci gang scheduleru pro IBM 340 node SP2 cluster při Národní laboratoři Lawrence Livermore. Během implementace se ukázálo, že využití systému vzrostlo z ~60% na ~90%, když jsme zaměnili FIFO scheduling za gang scheduling. Ingo, Richard Gooch a Hubertus pak diskutovali nad konkrétními způsoby implementace pod Linuxem.

Diskuse nad datem uvedení řady 2.6, 14 emailů

Hans Reiser se v průběhu diskuse zeptal, zda je Halloween posledním dnem [deadline] pro zasílání patchů nebo pro začlenění patchů. Hans chápe. že čím dříve je zašle, tím lépe, ale i když se jeho týmu podaří dokončit jádro reiser4 (stejná funkčnost jako verze 3, jen rychlejší a na lepší architektuře) včas, rád by přidal poté další funkce a zaslal je na poslední chvíli.

Andreas Dilger odpověděl, že změny, které nebudou v jádře na Halloweenu, budou muset počkat až na řadu 2.7. Tím, že Linus oznámil termín dopředu, dal lidem spoustu času zaslat věci připravené pro začlenění. Pokud budou důležité vlastnosti přidávány postupně (jak všichni doufáme), veškeré testování vývojových jader nepřijde nadarmo tím, že někdo zašle tunu patchů na poslední chvíli. Snažíme se, aby zde nebyl další rok navíc, ve kterém se přidávají nové vlastnosti do zmrzlého [frozen] jádra.

Exportovat či neexportovat, 8 emailů

Marcel Holtmann zaslal patch do ovladače PC Card v Bluetooth subsystému pro jádro 2.5.27. Někdo poznamenal, že Marcel používá symbol EXPORT_NO_SYMBOLS, který byl ale ve vývojové řadě označen za zastaralý [deprecated]. Alan Cox vysvětlil, že v řadě 2.4 je nutné používat tento symbol, kdekoliv je to možné, zatímco v řadě 2.5 je tento symbol nastaven automaticky, čímž vývojáři ušetří jednu řádku.

Marcel tedy zaslal opravený patch, ale Ingo Molnar se zeptal, proč je tolik důležité odstranit tento symbol ze zdrojáků. První odpověď zněla, že když se jedná o standard, měly by být odstraněny všechny výskyty. Ale Dave Jones měl jiný názor: odstranění znamená, že správce ovladače musí ošetřovat dvě různé větve pro řady 2.4 a 2.6. Ponecháním symbolu EXPORT_NO_SYMBOLS se nic nezkazí, ale umožní existenci jediného zdrojového kódu pro více verzí jader.

Varování: vážný problém s IDE ve vývojové řadě, 35 emailů

Bartlomiej Zolnierkiewicz oznámil, že IDE verze 99, použité v jádře 2.5.27, obsahuje chybu, která může zapřičinit zatuhnutí systému a ztrátu dat. Požádal lidi, aby tento kód nepoužívali. Andries Brouwer na druhou stranu napsal, že tato verze konečně odstranila jeho problémy.

Několik lidí se ptalo, jestli je chyba i ve verzi 100, což Bartlomiej potvrdil. Marcin Dalecki napsal, že chyba spočívá v nevhodném chování pri téměř zaplněné fronty pro asynchronní příkazy a zaslal patch, který kopíruje chování ovladače SCSI vrstvy. Bartlomiej však podotkl, že obsah tohoto patche byl v IDE před verzí 99 a byl to právě Marcin, který jej nahradil vadným kódem. Marcin přiznal, že to byla jeho chyba a že místo hledání inspirace v kódu ide-tcq se měl podívat do SCSI. Debata pak pokračovala nad implementačními detaily.

Tento článek vychází ze seriálu Kernel Traffic (http://kt.zork.net) a je zveřejněn pod licenci GPL verze 2.

       

Komentáře