Portál AbcLinuxu, 17. června 2024 22:03
První překlad populárního seriálu Kernel Traffic.
| dopisů | KB | autor | |
|---|---|---|---|
| 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 |
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ů.
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.
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.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: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."
"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."
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!"
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%."
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:
"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é.A k případu, kdy se stroj nezasekl, Linus pokračoval: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)."
"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."
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."
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.