Kernel Traffic #222 For 10 Jul 2003

Tady máte ovladač pro Touchpad Synaptics pro 2.5.70. Z velké části je založen na XFree86 ovladači. Tento ovladač provozuje touchpad v absolutním režimu a emuluje třítlačítkovou myš se dvěma kolečky. Umožňuje funkce:

• Poklepání více prsty.
• Vertikální a horizontální rolování.
• Rolování okrajů při posunování.
• Detekce dlaně.
• Rohové klepání.

Jedinou zásadní chybějící funkcí je konfigurace parametrů obladače za běhu. Jaký je nejlepší způsob implementace? Přemýšlel jsem o posílání EV_MSC událostí ovladači pomocí rozhraní /dev/input/event* a definování svých vlastních kódů pro různé parametry ovladače.

kdyby's tyhle fajn funkce dal prozatím do mousedev.c ovladače, ten touchpad by fungoval se standardními XFree bez toho ovladače založeného na událostech.

Zároveň připojuji práci Jense Taproggea na synaptice, kterou by's mohl začlenit...

Pro Jense: Promiň, že nepoužívám tvůj ovladač. Je také velmi dobrý. Doufám, že budeš moci pracovat spolu s Peterem, aby se do kernelu dostalo to nejlepší od obou.

Tento text popisuje několik položek z mého seznamu pro výzkum v rámci vývojového období kernelu 2.7. Nejdřív trochu historie.

V 2.3/2.4 bylo hlavní změnou linuxového subsystému správy paměti sjednocení stránkové a bufferové keše v tom smyslu, že byla odstraněna většina dvojitého uložení a kopírování z keše bufferu do stránkové keše už nebylo potřeba při každém zápisu do souboru. Ve 2.5 bylo hlavní změnou přidání reverzního mapování stránek. Na tom jsem se podílel i já a mojí motivací byla víra, že s implementovaným reverzním mapováním budou možná nebo rovnou jednoduchá výrazná vývojová vylepšení subsystému správy paměti. Ke komentáři nabízím tři hlavní projekty, které se mi doufám podaří dokončit během 2.7:

1. Aktivní deframentace paměti
2. Objekty stránkové keše s proměnnou velikostí
3. Keš fyzických bloků

Jsou seřazeny od nejméně po nejvíce kontroverzní. Myslím si, že všechny tři budou užitečnými zlepšeními linuxového subsystému správy paměti a doufám, že své přesvědčení dostatečně doložím následujícím textem. Samozřejmě, že fungující kód a benchmarky jsou konečným soudcem kvality, takže se v patřičné době objeví.

1. Aktivní deframentace paměti

   Pochybuji, že by někdo popíral, že je to žádoucí. Aktivní defragmentace eliminuje alokační selhání vyššího řádu u neatomických alokací a doufám, že všeobecně zlepší účinnost a transparentnost kernelového alokátoru paměti.

   Účelem aktivní defragmentace paměti je vychytání patových případů, nikoliv stát se kompletní náhradou stávajícího alokačního systému. Nejzřetelnějším a nejproblematičtějším patovým případem je ten, kdy všechny jednotky fyzické paměti daného řádu jsou vypotřebovány a alokátor tak má pouze dvě možnosti: čekat nebo selhat. Aktivní defragmentace zavádí třetí možnost, která by měla odstranit téměř všechny první případy a všechny druhé - s výjimkou situace, kdy je fyzická paměť skutečně z nějakého důvodu vypotřebována (tj. bona fide OOM [Out Of Memory] - vyčerpaná paměť).

   Představa je taková, že poběží defragmentační démon, který se probudí vždy když dostupnost nějakého alokačního řádu spadne pod určitou hranici. Defragmentační démon nejprve vyhledá v paměti snadno přesunutelné stránky, které mohou utvořit nové, volné jednotky daného řádu. Pokud tento přístup selže, mohl by jít démon až tak daleko, že by uvedl systém do klidu (technika již používaná při zamykání RCU) a přesunul nějaké ne tak snadno přesunutelné stránky.

   Aby bylo možno přesunout stránku fyzické paměti, musíme vědět, co na ukazuje. To často snadné, například v běžném případě, kdy na stránku ukazuje jediný ukazatel [pointer] a na stránce není prováděno IO. K přesunutí takové stránky potřebujeme jenom podržet zámek stránkové keše a zámek stránkové tabulky.

   Přesun anonymní paměti je s pomocí reverzního mapování stránek taky docela snadný. Musíme podržet příslušné zámky, projít seznam reverzní mapy stránky a aktualizovat ukazatele na novou kopii stránky. (Pokud přitom narazíme na nepěkné patové případy, mohli bychom se asi uchýlit zpět ke strategii zklidnění systému.)

   S některými složitými situacemi by se dalo vypořádat vytvořením nového interního kernelového API, které by poskytlo způsob, jak některý subsystém upozornit, že potřebujeme informaci o vlastnictví stránky, nebo že určité stránky by měly být realokovány podle přání defragmentačního démona. Je zřejmé, že je tu spousta příležitostí to v této oblasti překombinovat, ale na druhou stranu je tu příležitost pro důmyslnou designovou práci, která přinese mnoho užitku zatímco se vyhne potenciální komplexnosti.

   Defragmentace fyzické paměti je odrazovým můstkem pro stránky proměnných velikostí, které mám na seznamu jako další.

2. Objekty stránkové keše s proměnnou velikostí

   Tato položka se určitě bude zdát natolik kontroverzní, nakolik ta první kontroverzní nebyla. Snad pomůže když budete vědět, že můj prototyp kódu dělaný pod 2.4 naznačuje, že celý systém bude nakonec menší a možná i trochu rychlejší. Pokud budeme mít stránky s proměnnou velikostí, budeme vlastně moci odstranit zmatené bufferové seznamy, kterou jsou (někdy) připojeny ke stránkám, a nakonec odstranit buffery úplně. Tradiční bufferové IO a datové operace mohou být jednoduše vyjádřeny pomocí stránek za předpokladu, že stránkové objekty budou moci nabývat stejného rozsahu velikosti jako teď mohou buffery. Bloková IO knihovna se rovněž zkrátí, protože mnoho smyčkování [looping] a práce s se stavy [state handling] se stane nadbytečným.

   V této souvislosti je "proměnnou velikostí" míněno, že každý strukturovaný objekt stránky může představovat datový rámec jakékoliv binární velikosti, včetně menší než je fyzická stránka. Aby měla implentace hlavu a patu, všechny stránky daného adresného prostoru budou stejné velikosti. Navíc objekty stránek menší než fyzická stránka jsou povoleny pouze paměti, ze kterou stojí soubor, nikoliv anonymní paměti. Pravidla pro velké stránky je ještě třeba stanovit, nicméně vzhledem k tomu, že v této oblasti už probíhá mnoho práce, nebudu se tím dále zdržovat.

   Nejzajímavějším aspektem stránek proměnných velikostí je způsob manipulace s nimi. V tom by mohl být zmatek, ale naštěstí je možný jednoduchý přístup. Struktury substránky stránky nemusí být v mem_map; místo toho mohou být dynamicky alokovány ze slab keše. Účetnictví navíc, které je potřeba v rámci operací stránkové keše, abychom neztratili přehled, není nijak moc a především nepřidává více než jeden sub-cyklus v případech, kdy nejsou substránky použity (a i tak očekávám, že tohle zdržení bude vynahrazeno kratšími a přímějšími cestami v knihovně blokových IO).

   Jednou z výhod substránek, která možná není hned patrná, je příležitost k ušetření nějakého prostoru v mem_map poli: se substránkami začne být docela lákavé používat větší PAGE_CACHE_SIZE, tj. filesystém, který musí z nějakého důvodu používat malou velikost bloků, nebude způsobovat další velkou interní fragmentaci.

   Ale pro mě je největší předností substránek příležitost odstranění nadbytečných stavových informací, které jsou teď sdíleny mezi stránkami a buffer_heads. Až do nynějška jsem nebyl moc úspěšný v přesvědčování o důležitosti tohoto zjednodušení, ale tentokrát bude kód důkazem.

   Stránky proměnných velikostí přinesou okamžitý užitek souborovým systémům jako Ext2 a Ext3 v podobě větších limitů velikostí svazků a efektivnějších přenosů. Vedlejším účinkem bude pravděpodobná nutnost implementace tail merging-u u Ext2/3, aby mohla být kontrolována vzniklá zvýšená interní fragmentace - ale to je jiný příběh pro jinou konferenci.

   Stránky proměnných velikostí by měly hezky zapadnout do právě probíhající práce na manipulaci s velkými (2 a 4 MB) stránkami a především to bude šikovné pro architektury jako MIPS, které mohou optimalizovat stránky s proměnnými velikostmi v hardware.

   Pár krátkých bodů:

   • Racianalizace informací o stavech: stav reprezentovaný pouze v strukturované stránce, nikoliv strukturovaná stránka + seznam strukturované buffer_head
   • 1K filesystém již nejsou zvláštním případem
   • Účinnější IO cesta, hlavně pro 1K fs
   • Hromadné vyřazení kódu zjednodušením knihovny vfs blokových IO (nový kód je přídán do funkcí přístupu ke stránkové keši).
   • Jednotka zamykání stránek bude odpovídat filesystémové jednotce zamykání stránek - u většiny filesystémů
   • Generalizace superstránek
   • Výkon. Je to o trošku výkonnější. Eliminuje jednu třídu objektů, což nám umožňuje se více koncentrovat na zbývající třídu.
   • Velké souborové bloky (více fyzických stránek)
   • Odstranění hlaviček bufferů. Konečné použití hlaviček bufferů je datová rukojeť pro metadata filesystému (IO funkce bufferových hlaviček převezme BIO). V podstatě můžeme zaměnit strukturovanou hlavičku strukturovanou stránkou. Tento přechod může být postupný - po stanovení jedné hlavičky bufferu na jednu stránku.
   • Tlak paměti [memory pressure] teď reaguje pouze na jednu třídu objektu, což činí vyvažování více rovnoměrné.

   Závisí na:

   • Aktivní defragmentace

   Jak to funguje:

   • Velikost stránky je reprezentována proměnným počtem na základě jednotlivých adresných prostorů. V praxi je nejmenší 9 (512 bajtů na sektor), mohl bych si představit i 7 (každá ext2 inoda je samostatná stránka) nebo 8 (velikost sektoru na některých discích). Největší běžnou velikostí je 12. 13 dává velikost bloku 8K - např. Alpha. 21 a 22 dávají 2M a 4M velikost, což odpovídá hardwarovým možnostem x86. Další velikosti jsou možné na strojích jako MIPS, kde je velikost stránek možné řídit softwarem.
   • Implementováno pouze pro paměť, za kterou stojí soubor (stránková keš).
   • Z těchto operací se stanou zvláštní případy v přístupové vrstvě stránkové keše místo abychom měli ten zmatený kód v knihovně blokových IO.
   • Strukturované stránky substránek jsou alokovány dynamicky. Ale buffer_heads jsou pryč, takže je to podružná změna.

3. Keš fyzických bloků

   Tahle položka se přímo netýká správy paměti, ale protože to má vliv na stejné subsystémy, začlenil jsem ji do tohoto textu.

   Stručně, keš fyzických bloků umožňuje vfs účinně odpovědět na otázku: "máš-li fyzický datový blok, řekni mi zda a kde je mapován do jakéhokoliv adresného prostoru na stejném svazku". To nemusí být až tak velká změna v existující strategii: normální vyhledání a další operace zůstanou dostupné. Avšak vfs získá dodatečnou zodpovědnost za udržování zvláštního adresného prostoru pro každý svazek koherentního s četnými adresnými prostory, za kterými stojí soubor, na svazku.

   My už vlastně takové adresné prostory pro každý svazek máme a není už třeba tolik práce, aby bylo možno otestovat účinky zavedení koherence mezi těmito dvěma druhy adresných prostorů. Lze se na to dívat i tak, že plná koherence v této oblasti by dokončila práci na sjednocení stránkových a bufferových keší, která začala před pár lety.

   Vzhledem k tomu, že jsem tento nápad probral s několika vývojáři, vím, že mohou nastat složité problémy s některými komplexnějšími filesystémy, např s Ext3. Naštěstí může být prototyp keše fyzických bloků adekvátně otestován i jen s Ext2, a tam moc problémů není. Pokud se ukáže, že to přináší výkonostní zlepšení, které očekávám, bude stát za to pracovat na rozšíření funkčnosti i pro další filesystémy.

   Takže co jsou ta předpokládaná výkonostní zlepšení? Zatím jsem určil dvě:

   1. Fyzické přednačtení [readahead]. Můžeme tak natáhnout blok do stránkové keše předtím než budeme znát adresný prostor (pokud vůbec nějaký), do kterého vlastně patří. Potom, když už to víme, je účinné jej dodatečně vložit do svého adresného prostoru. Pomůže to v případě přenosu spousty malých souborů, který Linux v současné době nezvládá moc dobře.
   2. Raid 5. Největší problém s výkoností Raid 5 vychází ze skutečnosti, že při malých, izolovaných zápisech je nucen vypočítat každý nový shodný blok a přitom dochází k velkým rotačním zpožděním. Velká keš s tím hodně pomůže, ale velikost keše, kterou můžeme najít třeba ve špičkovém scsi disku není dostatečná k eliminaci těchto špatných efektů a každopádně se velkým problémem stane špatné rozložení. Mohli bychom také mít samostatnou keš fyzických bloků, ale to je plýtvání pamětí a způsobuje to zbytečné kopírování. Možnost implementace této velké keše přímo ve stránkové keši je proto velkou výhodou z hlediska šetření pamětí a omezení kopírování dat. Výhoda je rovněž kvůli zpožděním.

Shrnutí

Berte présím na vědomí, že všechno z toho je neoficiální, experimentální práce. Nicméně věřím, že všechny tři položky mají potenciál přinést výrazná zlepšení na poli spolehlivosti, účinosti a zřetelné správnosti.

Děkuji vám za trpělivost, kterou jste projevili dočtením až sem. Časový rámec pro tuto práci je:

• Začne jakmile se uzavře 2.5
• Prototypy by měly být zveřejněny krátce po té.

tady je to, co vím o různých sadách patchů:

z velké míry jsou všechny testovacím prostorem pro patche, které by jednou chtěly do vanilla kernelu

• mm - Andrew Morton - testovací prostor věci spojených s vm pro dev strom
• ck - Con Kolivas - patche pro desktop/interaktivitu
• kj - Údržbáři kernelu (Kernel Janitors) - testovací prostor pro čistky ve vývojových stromech kernelu
• mjb - Martin J Bligh - věci kolem škálovatelnosti
• wli - William Lee Irwin - další věci spojené s vm pro dev strom, na které Andrew Morton nemusí mít čas
• ac - Alan Cox - poslední dobou to byl testovací prostor pro nové ide
• lsm - Chris Wright - Linux Security Modules, poskytuje lehkou kostru s všeobecným využitím pro řízení přístupu
• osdl - Stephen Hemminger, ? možná velkopodnikové věci
• laptop - Hanno B?ck - nepotvrzené patche pro laptopy
• aa - Andrea Arcangeli - vm věci stabilní série
• dj - Dave Jones - čistky/AGP
• rmap - Rik van Riel - reverzní mapování vm pro 2.4
• pgcl - William Lee Irwin - ?

Další? Určitě. Možná by o tom měl být někde na webu udržován přehled.

Po té, co jsem se několikrát spálil, když jsem zapomněl na něco, co jsem měl udělat při poskytování patche oproti kernelu, vytvořil jsem Seznam úkonů před odevzdáním patchů, který najdete na

http://www.gelato.unsw.edu.au/IA64wiki/PatchReleaseChecklist

Pokud chcete, můžete do seznamu přidat další věci, na které jsem nepomyslel: ale musíte se zaregistrovat do Wiki.

údržbářská aktualizace, nic děsně nového nebo vzrušujícího. Především vylepšení zacházení s chybami a čistky (a pár opravených chyb - jen pro legraci).

GNU diff proti 2.4.21: ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/patchkits/2.4/2.4.21-atascsi1.patch.bz2

BK repositář: bk://kernel.bkbits.net/jgarzik/atascsi-2.[45]

Repositář 2.5 je s ohledem na nejpozdější scsi api trochu zastaralý, ale ata-scsi ovladač sám o sobě je 100% sladěn se svým 2.4 protějškem (kvůli vělkému množství změn v 2.5 scsi je 2.5 ovladač větví 2.4 ovladače).

podrobné změny:

• přidání automaticky generovaných docbook nápověd
• přidání atapi (ifdef je venku kvůli nedostatečnému řešení chyb)
• lepší průzkum ata včetně lepšího řešení chyb běnhem průzkumu
• více piix pci ids. vyšroubování ich5 sata max rychlosti na udma6.
• počátky podpory SYNCHRONIZE CACHE pro ATA disky
• lepší SCSI emulace pro ATA disky
• čistky, zjednodušení, opravy menších chyb
• pořádný kus práce na najdi-a-nahraď, s/ata_host/ata_port/

Příště přijdou na řadu nějaké další host ovladače společně s řešením atapi chyb...

gcc 3.3 je relativně nové a o _mnoho_ m=ně testované než 2.95. Nové gcc může buď obsahovat chyby nebo může odhalit chyby v kernelu, které nebyly předtím viditelné (např. díky lepší optimalizaci).

Většinou funguje gcc 3.3 bez problému (a mé domácí PC běží s 2.4.21 kompilovaným pomocí 3.3), ale pokud chceš stabilitu v pracovním prostředí, 2.95 (nebo neoficiální 2.96 >= 2.96-74) je ten doporučovaný kompilátor.