14.6.2007 00:10
Jardík | skóre: 40
| blog: jarda_bloguje
Rozbalit Rozbalit vše Re: Jaderné noviny - 23. 5. 2007
Portál AbcLinuxu, 5. května 2025 17:25
Aktuální verze jádra: 2.6.22-rc2. Přednačítání na vyžádání [On-demand readahead]. Sledování regresí. Grafický subsystém v jádře. Soubory jako adresáře.
Aktuální předverze řady 2.6 je (k 23. 5. 2007) 2.6.22-rc2, vydaná 18. května. Všelijaké opravy všude možně - připojený krátký changelog je docela dobře čitelný. Nejvýznamnější jsou asi další opravy SLUB a optimalizace epoll. Dlouhý changelog obsahuje všechny podrobnosti.
Aktuální verze -mm stromu je 2.6.22-rc2-mm1. Mezi nedávné změny patří přidání CFS plánovače, velká aktualizace Xen, aktualizace rozhraní signalfd(), která umožňuje přijetí více signálů v rámci jediného systémového volání, nový patch pro vyžádané přednačítání [on-demand readahead] (vizte níže) a systémové volání fallocate().
"Přednačítání" znamená spekulativní načítání části souboru do paměti v očekávání, že proces, který s daným souborem pracuje, ta data bude brzy chtít. Když přednačítání funguje dobře, bude mít proces, který je náročný na data, k dispozici potřebné informace, kdykoliv si o ně řekne - takže pak není nutné čekat na diskové I/O. Linuxové jádro už přednačítání provádí dlouho, ale to neznamená, že by to nešlo vylepšit. Fengguang Wu proto už pár let pracuje na sadě patchů pro podporu "přizpůsobivého přednačítání" [adaptive readahead].
Patche zůstávají v -mm z jednoduchého důvodu: jsou tolik komplexní, že není moc lidí, kteří by je dokázali pořádně zkontrolovat. Nový patch s přednačítáním na vyžádání je reakcí na požadavek Andrew Mortona na jednodušší patch, který by mohl proces začleňování rozhýbat. Nový kód je skutečně jednodušší, protože se zbavil většiny logiky, kterou obsahuje kompletní mechanismus přizpůsobivého přednačítání.
Patch s "on-demand" do velké míry reimplementuje to, co už teď dělá linuxové přednačítání, ale jednodušším, pružnějším způsobem. Stejně jako stávající kód, i on-demand patch udržuje "přednačítací okno", které sestává z části souboru začínající v místě, odkud aplikace naposledy četla. Stránky uvnitř přednačítacího okna by už měly být v keši stránek - a nebo aspoň předmětem I/O, aby se tam co nejdříve dostaly. Okno se posunuje kupředu souběžně s tím, jak aplikace data načítá.
Stávající kód vlastně implementuje okna dvě: "aktuální okno" (sada stránek v keši, mezi nimiž je i aktuální pozice aplikace) a "okno vpředu" [ahead window], což jsou nejčerstvější stránky, které právě jádro načetlo. Jakmile se pozice aplikace přesune z aktuálního okna do okna vpředu, je započata nová I/O operace, která vytvoří nové okno vpředu. Tímto způsobem se jádro snaží neustále držet dostatečný náskok před aplikací, aby byla data k dispozici, když jsou potřeba.
Patch s on-demand má okno jen jedno. Místo udržování samostatného "okna vpředu" říká nový kód o stránce (pomocí příznaku ve struktuře page), že je na "předvídacím indexu" [lookahead index]. Když se aplikace k označené stránce dostane, dojde k rozšíření přednačítacího okna a začne nová I/O operace. Proti používání příznaku se objevil určitý odpor, protože je těchto bitů neustále málo. Andrew Morton navrhl využít k tomu účelu heuristiku. Takový přístup by možná způsobil občasné špatné rozhodnutí, ale nic hrozného by se nestalo a na správný chod systému by to nemělo vliv.
Ačkoliv to vypadá, že patch on-demand toho moc nedělá, spočívá jeho výhoda v odstranění spousty komplikovaných záležitostí z aktuálního přednačítacího kódu. Je např. schopen se rozhodovat bez nutnosti se snažit o sledování událostí typu "pokus o přednačtení stránek, které jsou už v keši". Také kontroly sekvenčního přístupu nejsou tolik striktní, takže přednačítání zůstává aktivní i v situacích, kdy by jej stávající kód vypnul. Podle výsledků testů, které doprovázely patch, je dosaženo zrychlení aplikací o 0,1 až 8 % - i když v některých případech bylo naměřeno i zpomalení. Zajímavé je, že některé z nejlepších výsledků se projevily při běhu databáze MySQL, což není aplikace, u které by člověk očekával hodně sekvenční aktivity.
Tento patch je určitě dost jednoduchý na to, aby mohl být zkontrolován; pokud se neobjeví vážné výhrady, mohl by být připraven do 2.6.23. Pak by třeba Fengguang mohl začít pracovat na přidávání komplexnější logiky, která tvoří mechanismus přizpůsobivého přednačítání.
Následující obsah je © KernelTrap
21. kvě, originál
Sledování regresí v nových verzích jádra se ujal Michal Piotrowski, který spravuje na Kernel Newbies wiki stránku "known regressions" [známé regrese]. Seznam je rozdělen na sekce a po každém vydání (release candidate) odesílán do LKML.
21. kvě, originál
Jesse Barnes poslal shrnutí probíhajího úsilí o vylepšení jaderné podpory grafiky: Ve spolupráci s vývojáři framebufferu pracujeme na vylepšení grafického subsystému, abychom do světa linuxové grafiky vnesli trochu pořádek a zbavili se současné situace, při které o kontrolu grafických zařízení bojuje několik jaderných a uživatelských ovladačů. A vysvětlil: Je hned několik důvodů, proč přidat nastavování režimů a podporu více monitorů [multihead] přímo do jádra: suspend/resume [uspávání/probouzení], debugování (např. panic), využití mimo X a spolehlivější přepínání VT. Jesse přidal i podrobnosti o každém z těchto důvodů a nastínil aktuální stav kódu:
Současný kód je v mnoha ohledech nekompletní: je třeba (znovu) přidat zamykání u částí, které manipulují se seznamy, potřebujeme lepší logiku pro počáteční konfiguraci, podpora je zatím dostupná jen pro ovladač Intelu (a i tak chybí funkce pro suspend/resume a akcelerovaný FB), musíme kontrolovat, jestli režim odpovídá možnostem monitoru (které získáme buď z EDID nebo od uživatele), kód pro nastavování DRM režimu stále nepoužívá generování módu založené na CVT a GTF a ještě mnohem více věcí. Doufám, že díky vystavení kódu zjistíme, jaké mají lidé představy nebo požadavky na linuxovou grafiku, takže si budeme moci stanovit priority.
23. kvě, originál
Miklos Szeredi poslal patch, který umožňuje přistupovat k souborům jako k adresářům. Jako příklad nabídl třeba přístup k obsahu zkomprimovaného tarballu jako k obyčejnému adresáři. Poznamenal, že to nemusí být jediný způsob využití patche: Někdo by mohl navrhnout využití rozhraní třeba pro přístup ke streamům, větvím zdrojů nebo rozšířeným atributům. Patch se však zabývá pouze neadresáři, takže adresáře by z takového rozhraní byly vyloučeny. Jinak však kód nijak neomezuje koncept 'soubor jako adresář' - jen přidává infrastrukturu, která by ty šílenosti podporovala. Al Virovi se patch zalíbil a řekl: Večer se na to podívám; zní to zajímavě - za předpokladu, že nenarazíme na nějaké vážné problémy se zamykáním a revalidační logikou. Miklos a Al pak probírali implementační detaily.
Miklos dále vysvětlil, že to funguje pomocí připojování [mount] se speciálními vlastnostmi: Je-li k neadresářovému objektu přistupováno s koncovým lomítkem, může se souborový systém rozhodnout umožnit k souboru přístup jako k adresáři. V takovém případě je 'něco' (což dodá souborový systém) připojeno nad neadresářový objekt. Pokud za názvem souboru není lomítko, připojení se neprovede. Připojení zůstane, pouze pokud na něj odkazuje nějaký externí objekt - např. pwd nebo otevřený soubor. Když odkaz zmizí, dojde k automatickému odpojení. Na rozdíl od 'skutečných' připojení to nezablokuje unlink(2) nebo rename(2) na původním objektu.
14.6.2007 00:10
Jardík | skóre: 40
| blog: jarda_bloguje
podpora je zatím dostupná je pro ovladač Intelu
sed 's/dostupná je/dostupná jen/g'
14.6.2007 01:30
Marek Bernát | skóre: 17
| blog: Arcadia
Slovo "aplikace" snad Microsoft ještě patentováno nemá.
Jo, řešení, to už je tak otravný! Vždyť to ani nedává smysl... Obzvlášť kompletní řešení mi pijou krev, každý střevo se s tím vohání, aby bylo v biznise IN, kompletní řešení pro vaše účetnictví, kompletní řešení pro vaši firmu, kompletní řešení pro odvod vašich fekálií... Já bych nejradši kompletní řešení pro 220V terapii vylízanců, co říkají "(kompletní) řešení".Náhodou, nazývat to komplexní řešení je často správné. Každé komplexní řešení přeci zahrnuje netriviální imaginární část
16.6.2007 19:31
Marek Bernát | skóre: 17
| blog: Arcadia
15.6.2007 22:55
Marek Bernát | skóre: 17
| blog: Arcadia
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
