Jaderné noviny 40

4. 2. 2002 | Leoš Literák | Jaderné noviny | 1360×

První překlad populárního seriálu Kernel Traffic.

Statistika za období 3.10. - 15.10.1999

1682 dopisů o celkové velikosti 6579 KB
465 různých autorů, z nichž 226 poslalo více než jeden dopis.
 

Nejaktivnější autoři

dopisů	KB	autor	email
60	253	Alan Cox	alan@lxorguk.ukuu.org.uk
58	200	Stephen Frost	sfrost@mail.snowman.net
57	181	Shawn Leas	SLEAS@videoupdate.com
43	190	Horst von Brand	vonbrand@inf.utfsm.cl
42	111	Dan Hollis	goemon@sasami.anime.net
39	164	Alexander Viro	viro@math.psu.edu
30	138	Khimenko Victor	khim@sch57.msk.ru
29	115	Andrea Arcangeli	andrea@suse.de
28	141		danielt@digi.com
28	133	Horst von Brand	vonbrand@sleipnir.valparaiso.cl

Nejzajímavější diskuse

1. Vazba procesu na CPU
2. Velká diskuse o devfs
3. Problémy s BIOSem
4. Zmatky kolem IDE při SMP ve stabilních jádrech
5. Dokument o jemnozrných OS časovačích
6. Linus využívá svého vlivu při směřování vývoje PCI
7. Emulace FPU

Vazba procesu na CPU

3.-15. 10.1999, 21 dopisů

Avi Kivity zaslal patch vůči 2.3.18, který umožní určit, na kterém procesoru smí proces běžet. Přidal i malý program na demonstraci této vlastnosti. Rik van Riel poznamenal, že tento patch přidává časově náročný kód do funkce goodness(), která je volána pro každý proces při přeplánování. To způsobí zpomalení celého systému. Navrhl nastavení procesoru raději během navazování procesoru.

Tim Hockin také poznamenal, že i tyto vlastnosti Aviho patche jsou již zahrnuty v programu pset. Andrea Arcangeli se zeptal, jaký je důvod pro tuto vlastnost. Avi řekl, že chtěl taky trochu přispět do vývoje jádra malým dílkem. Na to Andrea odpověděl, že jeho SMP plánovací patch bude lépe optimalizovat než pouhé přiřazení procesoru. Avi vyzkoušel pár benchmarků, aby zjistil penalizaci při přesunu procesu na jinou CPU. Výsledkem bylo, že navázání procesu na specifický procesor nezlepšuje výkonnost systému, aspoň na menších strojích. Není si však jist s výsledky na strojích s větším počtem procesorů.

Velká diskuse o devfs

3.-14.10.1999, 631 dopisů

Tato debata začala již na konci června poměrně nevinnou debatou nad alokací čísel pro USB zařízení. Pavel Machek oznámil, že USB konečně začíná být použitelné a že je tedy čas alokovat záznamy v adresáři /dev pro různá USB zařízení. Alokoval 32 záznamů pro 16 zařízení, ale Steffen Grunewald požádal o dlaší záznamy pro zařízení jako monitory, reproduktory apod. Na to Dan Hollis odpověděl, že "Zoufalá potřeba po devfs se stává opět jasnější." Za tímto bodem už nebylo návratu. Debata zuřila asi jeden a půl týdne, generujíce přes 600 dopisů. Linus, ačkoliv se již vrátil z prázdnin, do debaty nezasáhl, zatímco Alan odpovídal pouze na technické detaily.

Problémy s BIOSem

10.-14.10.1999, 17 dopisů

Graham Murray vyzkoušel 2.3.20, ale zjistil, že jeho kernel havaruje během startu. Nemohl však poslat přesný popis chyby, neboť text skroloval příliš rychle. Horst von Brand potvrdil tento problém, stejně jako Tim Waugh. Tim pak přidal do kernelu kód 'for(;;)' za zdroj chyby, aby zachytil přesný text chyby. Poslal jej do konference a Linus odpověděl:


"Skoro určitě je to způsobeno vadným BIOSem.

Není to nic překvapivého, je to jeden z problemů, které jsme vždy měli - 32-bitové BIOSy mají tendence k chybám, protože je nikdo netestuje. Když PCI kód zavolá BIOS, aby zjistil tabulku přerušení, BIOS je zmaten a havaruje. Kód, který zjišťuje IRQ čísla pomocí BIOSu, je nově přidán do jáder od verze 2.3.19.

Martine, prostě změňme předvolené hodnoty: nevolejte BIOS automaticky (možná bychom mohli mít příkaz jádra pciirq=bios pro ty dvě osoby, které to potřebují a mají funkční BIOS), protože se vsadím, že toto není poslední oznámení o strojích, které nebootují, až se do testování zapojí více lidí. A to není, jako když máme IRQ  čísla špatná, když si je najdeme ručně.

Mít špatné IRQ občas je pořad lepší než tajemné havarie při startu. Zařízení nebude fungovat, ale bude možné jej odlaďovat. A je pravděpodobnější (skoro jisté), že je mnohem více vadných 32-bitových BIOSů než vadných počítačů, na kterých nedokážeme zjistit IRQ čísla bez BIOSu."

Alex Nicolaou navrhl, aby se použily oba způsoby a pak se porovnaly výsledky jádra s výsledky volání BIOSu a zobrazením chybové hlášky, pokud by se výsledky lišily. Ale Linus odpověděl:

"Toto není o tom 'když se liší'.

Pokud je BIOS vadný a vy jej zavoláte, počítač havaruje. Neexistuje způsob, jak se vybraně zotavit [gracefully recover].

Proto nechci používat volání BIOSu. Pokaždé, kdy jsme používali volání BIOSU (APM, standardní PCI konfigurace a teď informace o PCI přerušení), byla zde nezanedbatelná část BIOSů, které byly tak vadné, že počítač havaroval po jejich použití.

Proto prohlížení tabulek v paměti je v pořádku. Pokud totiž parsujete tabulky, můžete se aspoň snažit se zotavit z chybných tabulek.

Mimochodem, toto je jeden z důvodů, proč jsem přesunul APM věci do zvláštního procesu - stále padá, ale nyní pád BIOSu aspoň může být nějak ošetřen (neříkám, že je to bezpečné, ale hloupé náhodné chyby způsobené tím, že BIOS očekává na určitých adresách datové struktury DOSu a Windowsu, způsobí čisté zabití a ne nic horšího).

Ale já nechci, aby nic tak kritického jako scanování PCI záviselo na něčem tak nespolehlivém. Ruční způsob může být také bolestivý, ale aspoň můžeme opravovat chyby a zjišťovat, co děláme špatně."


Michael Cummins řekl, že "Přál bych si, aby chybové hlášky způsobené vadnými BIOSy končily v poštovní schránce výrobců BIOSu, a ne vaší schránce." a Linus odpvěděl:

"Hmm, věci se mají tak, že pokud by tam skutečně skončily, oni by prostě pokývali hlavou a řekli 'Smůla'. I kdyby se snažili opravit tuto chybu v nových verzích BIOSu (velké kdyby), stejnak by tu zůstaly existující BIOSy s touto chybou. A přestože můžete nahrát novou verzi BIOSu na novějších strojích, stejně to většina lidí nechce dělat.

A ano, je to bludný kruh. Protože BIOSy bývají vadné, nikdo (včetně MS) je nepoužívá, proto je nikdo netestuje, takže se nikdy neopraví, proto ...

Proto je lepší považovat BIOS jen za oslavovaný nahrávač a nic víc. Záviset na něm jen tolik, abychom dostali stroj co nejblíže k použitelnému stavu, ale být připraveni si udělat všechno ostatní sami."

Zmatky kolem IDE při SMP ve stabilních jádrech

10.-12.10.1999, 7 dopisů

Marc Duponcheel dostal 'oops' na jádře 2.2.13pre15 a usoudil, že "něco obecného mezi 2.2.13pre14 a 2.2.13pre15 způsobilo konflikt mezi SMP-CPU a IDE-HD". Alan odpověděl: "Je to trochu složitější. Problém je, že 2.2.13pre14 může uváznout [deadlock] v IDE kódu pro SMP. 2.2.13pre15 opravuje toto uváznutí, ale otevírá [race condition] v obsluze požadavků. Opravit to znamená, že někdo bude muset konečně spravit uzamykání v IDE ovládači a obsluze fronty požadavků místo nekonečného záplatování špatné práce." Pak dodal: "A nebudu to já."

Andre Hedrick odpověděl: "O tom slyším poprvé.....vrrr...." A začal vysvětlovat: "Ano, začíná to být nepřehledné a dlouhé... Budu teď mimo na dva nebo tři týdny kvůli stěhování ... takže jakákoliv úvodní práce bude užitečná. Protože stará ochrana zmizela a nevrátí se, bojím se, že se budu muset vrátit do minulosti a najít chybu během uvedení SMP ... v 2.1.90 až 95 to bylo. Pamatuji si, že to bylo kolem 2.1.122, odkud bylo možné vzít kousky a jít ... takže se zachytávám prvního dne."

Alan řekl: "Nezávidím nikomu, kdo se bude snažit opravit chybu zamykání IDE - je ošklivá." A pokračoval: "Už jsem si prohlížel zamykání a je to opravdu těžké sledovat, co má být zamčeno. IRQ je opravdu škaredé. Nemůžeme povolit, aby se objevilo přerušení - ani chvilkově během sekvence zamykání a zákazu IRQ, a ještě nemůžeme zakázat IRQ držícím zámek, protože IRQ může právě probíhat. Mám ty věci kolem fronty požadavků částečně opraveny, potřebuji trochu protřídit propagaci chyb."

Vrtajíce se dovnitř, Andre oznámil: "Našel jsem několik starých __cli a ide__sti, které se tu motají a nikdy nenastavují [spinlock]. Tyto nejsou vůbec párovány a prohlížejí se, nastavují se a mazají se v různých voláních." Později ve stejném dopise přidal: "je tu nekonečně mnoho kombinací uváznutí, které se náhodně ruší ... znáte tu starou ruskou hru s revolverem ... PRÁÁSK!!!"

Marc vyzkoušel 2.2.13pre16 a ohlásil: "Verze 2.2.13pre16 pracuje spolehlivě již po několik hodin, takže děkuji každému za práci, kterou (je třeba?) udělal!"

Dokument o jemnozrných OS časovačích

12.10.1999, 1 dopis

Mohit Aron oznámil: "Rád bych pověděl linuxové komunitě o mém článku nazvaném 'Jemné časovače: efektivní podpora mikrosekundových softwarových časovačů pro sítě', který se objeví na SOSP '99. Abstrakt dokumentu je uveden níže. Zkompresovaný postscript se nachází na adrese http://www.cs.rice.edu/~aron/papers/soft-timers.ps.gz "

Přiložený abstrakt:

"Tento dokument navrhuje a vyhodnocuje softwarové časovače, novou vlastností operačních systémů, která umožňuje efektivní plánování softwarových událostí při granularitě až k desítkám mikrosekund. Softwarové časovače mohou být použity k zabránění přerušení a k snížení přepínaní kontextů při zpracování sítí bez obětování malých zpoždění při komunikaci.

Přesněji, softwarové časovače umožní transportním protokolům, jako je TCP, efektivně vykonávat zasílání paketů podle tříd [rate based]. Experimenty dokazují, že toto dokáže zlepšit čas HTTP odpovědi na širokopásmových sítích až o 89% při 2-6% zvýšení zatížení CPU.

Softwarové časovače také mohou být použity pro [network polling], což eliminuje síťová přerušení. Experimenty ukazují, že tato technika může zvýšit výstup z web serveru až o 25%."

Linus využívá svého vlivu při směřování vývoje PCI

13.-14.10.1999, 6 dopisů

Martin Mareš oznámil: "Pokud máte jakýkoliv problém s PCI v 2.3.21, prosím zkuste můj nový patch přístupný na adrese ftp://atrey.karlin.mff.cuni.cz/pub/linux/pci/alpha/l-pci-2.3.21.gz ."

Poslal seznam změn:

• přidáno pci_set_power_state() pro probouzení a uspávání PCI zařízení.
• přidáno pci_enable_device(), které volají ovládače PCI před tím, než začnou komunikovat se zařízením. Funkce požádá nízkoúrovňový kód o povolení regionu a probudí zařízení, pokud je uspáno.
• pci-i386: povolí zařízení, pouze pokud o to žádá ovládač, nikoliv ale automaticky. Kromě strojů s VadnýmBIOSem(tm) by ovládače měly fungovat beze změn, opravím je později.
• změny v Documentation/pci.tx
• pci-pc: vyhnout se IRQ 14 a 15
• devlist.h se nyní generuje automaticky z pci.ids, přiložen skript
• pci-pc: nepoužívá se automaticky BIOS pro zjišťování IRQ. Pro ruční aktivaci použijte 'pci=biosirq'.
• pci-pc: pozná sekundární sběrnici na Compaq a RCC mostech [bridge] (díky Doug Ledfordovi za jeho patch do 2.2, pouze jsem jej přeportoval do 2.3)
• pci-pc: nepoužívá se automaticky scanování [peer bridge] hrubou silou, neboť to bylo nahrazeno různými kličkami specifickými pro chipsety a triky s IRQ tabulkou. Používejte 'pci=peer', jen když to skutečně potřebujete.
Někdo oznámil, že pokud má vypnuto USB IRQ v BIOSu, jeho stroj se zasekne, zatímco se zapnutou podporou USB IRQ je vše v pořádku. K zaseknutí Linus řekl:

"Zdá se, že je to kvůli přehnaně chytrému IRQ kódu, který je nově zahrnut od 2.3.19 a myslí si, že může spravit věci, které BIOS nechal vypnuté.

Toto je úplně smrtící, protože BIOS v tomto případě zjevně nechal IRQ vypnuto z velmi dobrého důvodu: pravděpodobně směřuje USB IRQ do SMI a provádí kouzelné 'emulace starých zařízení s USB' v SMM modu.

Když potom nový PCI kód změní směrování IRQ bez toho, aby se staralo o dvě úrovně ovladačů používajících ty přerušení (ovládač jádra pro PS/2 myš a ovládač SMM modu BIOSu, který povolil USB zařízení), skončíš s nekonečným proudem USB přerušení mířících do špatného ovládače (který nebude vědět, co s nimi a ony budou stále přicházet a nikdy neskončí, protože je nikdo nebude umět zastavit)."

A k případu, kdy se stroj nezasekl, Linus pokračoval:

"Toto je způsobeno tím, že když je USB přerušení povoleno, BIOS neaktivuje ovládač USB, protože si myslí, že OS si bude řídit USB přerušení sám.

Martine, 2.3.19 kód musí zmizet. Nemůže být opraven a takhle to nemůže pokračovat.

Možná UŽ rozumíš, proč jsem stále narážel a narážel na otázku NEPOKOUŠENÍ se opravovat náhodné PCI stavy bez toho, aby o to výslovně požádal některý ovládač? To se bude dít tak dlouho, dokud si PCI subsystém bude myslet, že ví, co je JedináSprávnáVěc(tm). Ale PCI subsystém opravdu neví vše v případě chybějicího ovladače a může zde být opravdu dobrý důvod, proč I/O oblast není namapována nebo IRQ není povoleno.

Proto věci kolem chybějícího směrování přerušení  nebo chybějícího I/O mapování apod. mohou být opravenu pouze OVLADAČEM. Protože od chvíle, kdy je ovladač povolí, víme, že budou správně spravovány (nebo aspoň od této chvíle to můžeme považovat za chybu ovládače a spravit to na správném místě). Ale ne před tím."

Emulace FPU

15.-16.10.1999, 16 dopisů

Luke Deller a Daniel Potts zaslali patch na emulaci některých instrukcí Alphy a během diskuse Alan mínil, že emulace instrukcí pro práci s pohyblivou čárkou by měla být přemístěna do uživatelského prostoru. Linus odpověděl:

"Nemyslím si, že jsi zažil horor Minixu a emulaci FPU v uživatelském prostoru. Je to příšerná bolest - na jedné straně přetížení [overloading] SIGFPE se vším, co to obnáší, na straně druhé nějaký skrytý magický signál nahrávající FP knihovnu na požadavek. A pak core dumpy, které se nedají vyřešit ...

Takže si myslím, že je nesrovnatelně lepší toto mít v jádře - z řešení s uživatelským prostorem by všichni začali šílet po pětisté chybě v konfiguraci nějaké sdílené knihovny. S jaderným řešením zde nehrozí žádné překvapivé interakce, pouze spousta rozumně komplexního kódu, který už stejnak byl skoro celý napsán.

NICMÉNĚ, je možné, že se časy změnily a že nyní by bylo lepší to mít v uživatelském prostoru prostě proto, že už to není a nebude problém a v uživatelském prostoru můžete dělat finty, které si nemůžete dovolit v kernelu z bezpečnostních důvodů.

Dnes už ale na tom nezáleží. Nemyslím si, že by se FP emulátor za poslední rok nějak změnil a funguje. Je tu ještě pár problémků jako třeba ukládání stavu FPU, ale ty už jsou vyřešeny."

---

Tento článek je překladem serveru Kernel traffic a je zveřejněn pod licenci GPL verze 2. Přeložil Leoš Literák.        

Komentáře