Portál AbcLinuxu, 6. května 2025 17:43
Jaderné noviny - 29. 3. 2006
Články
-
Jaderné noviny - 29. 3. 2006
Aktuální verze jádra: 2.6.16.1. Co bude nového v 2.6.17, část 2. Rámec pro pravidla nahrazování stránek. Správa stromu 2.6.16.y. Co z -mm půjde do 2.6.17. SCSI ID.
Aktuální verze jádra: 2.6.16.1
Aktuální verze stabilního jádra je 2.6.16.1. Vydána 27.
března. Zároveň vyšla i verze 2.6.15.7. Oba patche obsahují
slušnou řádku důležitých oprav, některé se týkají bezpečnosti.
Během minulého týdne nevyšla žádná vývojová předverze. Do hlavního git
repozitáře však patche proudí vysokým tempem; viz shrnutí níže.
Aktuální -mm strom je 2.6.16-mm2. Mezi
nedávné změny patří možnost volat poll() na sysfs soubory (viz článek na LWN),
podpora 64bitových I/O a pamětových zdrojů, podpora futexů, které dědí
prioritu, a nová sada patchů pro správu centrálního času.
Co bude nového v 2.6.17, část 2
Záplava patchů, které se hrnou do hlavního stromu, pokračuje bez ustání
- i když čas na přidávání nových funkcí brzy vyprší. Následuje přehled
nejzajímavějších částí kódu začleněného od minulého
týdne:
- Patch pro podporu lehkých robustních
futexů.
- Vrstva softwarového RAIDu (MD) zvládá za běhu měnit velikost RAID5
polí.
- Z SCSI subsystému byla odstraněna podpora devfs. V mnoha jiných
částech jádra však stále zůstává.
- Patch s uživatelským software
suspend.
- Velká aktualizace XFS.
- Softwarová implementace MAC pro 802.11. Byla také začleněna verze 20
wireless extensions API [rozšíření pro bezdrátové sítě].
- Byl přidán reverse-engineered [rozluštěn z binárky] ovladač Broadcom 43xx.
Tím pádem se seznam Linuxem podporovaných bezdrátových síťových karet
znatelně rozrostl.
- Mechanismus "rozložení paměti" [memory spreading] lze použít k rozprostření keše stránek a
alokací v bufferech souborových systémů přes všechny uzly NUMA
systému.
- Dvě nové
operace fadvise() pro ovládání asynchronního vypisování
souborů.
- Podpora přeskupovacích funkcí v linkovaném obraze jádra. Účelem je
dát dohromady hodně používané části kódu jádra, aby se tato vytížená
oblast vešla do jediného TLB záznamu. V současné době má infrastrukturu
pro přeskupování pouze x86-64.
- Souborový systém ext3 získal možnost alokovat a mapovat více bloků,
což zvyšuje výkon při sekvenčních přístupech k souborům.
- Nově přidaná plánovací doména [scheduling domain] reprezentuje
vícejádrové systémy.
- Byl začleněn nový RTC subsystém, který poskytuje podporu pro různé
real-time hardwarové hodiny.
Bude-li dodržen obvyklý postup, přestanou být nové funkce přidávány
někdy kolem konce měsíce a 2.6.17-rc1 vyjde krátce poté.
Rámec pro pravidla nahrazování stránek
"Panejo."
Tak reagoval Andrew Morton na
34dílný patch od Petera Zijlstry, který vytváří abstraktní API pro pravidla
nahrazování stránek. Kód nahrazování stránek je v samém jádře systému
virtuální paměti; jde vlastně o heuristické rozhodování o tom, které
stránky by měly být vyhozeny z hlavní paměti a zpřístupněny pro jiné účely.
Jde trochu o černou magii; ačkoliv je snadné poznat, kdy systém spravuje
paměť špatně, není často vůbec jasné, jak situaci vylepšit. Správa paměti v
Linuxu byla dlouhé roky choulostivou otázkou, ale nyní se zdá, že ve
většině případů funguje dobře. Vzhledem k tomu, že se všechen ten záludný
kód konečně dostal do poměrně dobrého stavu, proč by se v něm chtěl ještě
někdo vrtat?
Odpovědí je, že alternativní mechanismy pro nahrazování stránek jsou
docela aktivně zkoumány, a Linux by z této práce mohl těžit. Konec konců
málokdo by řekl, že linuxová virtuální paměť funguje tak dobře, že už by
nebylo co vylepšovat.
Tato velká sada patchů vytváří API pro algoritmy nahrazování stránek a
umožňuje jejich libovolné střídání. Tedy, přinejmenším při restartu; v
současné době neexistuje možnost nahrávat nahrazovací algoritmy jako
moduly nebo je měnit za běhu. Ale při konfiguraci jádra mohou
administrátoři zvolit systém nahrazování stránek, který nejlépe vyhovuje
jejich podmínkám. Programátoři, kteří pracují na virtuální paměti, si
mohou hrát s různými algoritmy, aby zjistili, jak to s nimi funguje.
Aby mohl nahrazovací algoritmus s tímto API fungovat, musí definovat
sadu specifických funkcí. Takže například existuje dvojice inicializačních
funkcí:
void page_replace_init(void);
void page_replace_init_zone(struct zone *zone);
Tyto funkce jsou volány při bootu a připravují nahrazovací kód k tomu,
aby fungoval se systémem, na kterém poběží.
Pokud jádro něco ví o konkrétních stránkách, může to nahrazovacímu
algoritmu sdělit pomocí následujících volání:
void page_replace_hint_active(struct page *page);
void page_replace_hint_use_once(struct page *page);
První je voláno, když si jádro všimne, že stránka je aktivně používána.
Druhé značí, že stránka pravděpodobně nebude v blízké budoucnosti
používána.
Existují různé další funkce pro udržování pořádku, ale jádrem API je
tato funkce:
void page_replace_candidates(struct zone *zone, int count,
struct list_head *list);
Ta musí vybrat až count stránek z dané zone jako
kandidáty na vyhození. V tom okamžiku nahlédne nahrazovací kód do své
křišťálové koule, aby zjistil, které stránky nebudou v nejbližší době
použity; ty budu vyčleněny a vráceny jádru.
Další funkce se věnují otázkám jako je migrace stránek, sledování
neresidentních stránek, vypisování informací z nahrazovacího kódu a tak
dále. Seznam a popis těchto dalších funkcí naleznete v dokumentačním
souboru.
Sada patchů rovnou obsahuje čtyři různé nahrazovací mechanismy. První je
kód z aktuálního jádra, který využívá metodu LRU (least-recently-used =
nejdříve použité), upravený tak, aby používal nové API. Další je CLOCK-PRO
algoritmus. Pak implementace techniky CART vysvětlené v této práci
[PDF]. A nakonec jednoduchý systém pro náhodné nahrazování, zjevně jen
tak pro legraci. I když, ten patch pro náhodné nahrazování je
díky své jednoduchosti vhodným startem pro ty, které zajímá, jak vypadá
modularizovaný nahrazovací algoritmus.
Patch je trochu podobný kódu pro vybírání CPU
schedulerů, který umožnuje měnit plánovací algoritmus. Patch je i
nadále spravován, ale od doby, kdy byl v roce 2004 poprvé představen, se
nikdy vážněji neuvažovalo o začlenění do hlavního jádra. Daleko větší
zájem je o nalezení chyb - jsou-li nějaké - v současném kódu, ne o
vytváření mechanismu pro zkoušení úplně jiných implementací. Proto svou
odpověď Andrew Morton doplnil takto:
Spíše než čtyřikrát celou věc nahrazovat bych uvítal přesný popis těchto
problémů. Zjistit, jestli by nešlo situaci zlepšit po částech místo toho,
abychom to rovnou celé vyhodili...
Linus má podobný názor a kromě toho není
přesvědčen, že by nahrazování stránek byl skutečně problém zasluhující
zvláštní pozornost "Připadá mi to jako univerzitní
výzkum."
Zastánci patche tvrdí, že doopravdy existují situace, při kterých jde
současný kód do kolen. S ohledem na to by se zdálo, že dalším logickým
krokem by bylo shromažďovat informace o případech, ve kterých linuxová
správa paměti selhává. Pak mohou vývojáři začít uvažovat o tom, co je
potřeba udělat pro to, aby byla tato selhání vyřešena. I kdyby patche
nebyly nikdy začleněny, vypadá to, že by mohly pomoci nastartovat další
fázi práce na algoritmech linuxové správy paměti. A to by bylo dobře bez
ohledu na to, jestli do jádra půjdou nebo ne.
Poznámka redakce: Na podnět několika čtenářů jsem se dohodl s Jeremy Andrewsem na využití materiálů z KernelTrap.org. Jaderné noviny tedy budou kombinovat informace ze dvou zdrojů: LWN.net a KernelTrap.
Následující obsah je © KernelTrap
Správa stromu 2.6.16.y
23. bře, originál
Spolu s vydáním jádra 2.6.16 se Adrian Bunk vrátil ke svému dříve probíranému
záměru spravovat do budoucna jádro 2.6.16.y. První verze 2.6.x.y byla
2.6.8.1 od Linuse Torvaldse - rychlá jednořádková oprava v NFS. Myšlenka
byla znovu vytažena o pár měsíců později v říjnu 2004 [článek], ale
chytla se až v březnu 2005 [článek] [článek]. Počínaje
jádrem 2.6.11 byla procesu dána jasná pravidla a Greg KH spolu s Chrisem
Wrightem začali oficiálně spravovat verze 2.6.x.y [článek] - dokud
nevyjde 2.6.(x+2). Například nyní budou Greg a Chris aplikovat stabilní
patche na jádro 2.6.16.y, dokud někdy v budoucnu nevyjde 2.6.18.
Adrian plánuje v tu chvíli převzít vývoj jádra 2.6.16.y a
spravovat ho podobně jako je spravována řada 2.4. Má v úmyslu strom
udržovat tak dlouho, dokud jej lidi budou používat a budou posílat patche.
Minule se v debatě o tomto záměru objevily smíšené reakce. Greg KH
varoval: "Chceš-li to dělat dlouhodobě, spolkne to
spoustu času a
energie. Být tebou, tak naslouchám těm, kteří tento typ jader spravovali a
spravují; není to rozhodně nic snadného."
Co z -mm půjde do 2.6.17
27. bře, originál
Andrew Morton [interview] sestavil seznam patchů
ze svého -mm stromu, ve kterém u každé položky shrnul své úmysly ohledně
toho, jestli ji bude tlačit dál k Linusovi pro začlenění do 2.6.17 nebo ne.
Komentáře u patchů se pohybují od prostého "začlením" až po
přenechání jiným k posouzení. Jeden ze zábavnějších komentářů se objevil u
sady 33 patchů, kde Andrew poznamenal: "Takhle se
Oleg vyřádil v
jádře jádra. Je tam hromada materiálu Pravděpodobně to celé pošlu Linusovi
a požádám ho, aby to prošel (tj. myji si ruce)." Později vysvětlil:
"je to prostě spousta kódu v delikátních oblastech,
kde pracuje jen pár
lidí, a pro které je obtížné najít někoho, kdo by to
zkontroloval."
Jedna sada patchů byla odmítnuta s komentářem: "Pořád pro tohle
neznám přesvědčivý argument." Šlo o předběžné načítání
swapu od Cona Kolivase [interview]. Funkce pak byla
diskutována v několika následujících vláknech. V odpovědi na připomínky
Jense Axboea vysvětlil Con implementaci trochu podrobněji: "Je-li systém
nečinný, nic nás načtení těchto stránek nestojí (v laptopovém režimu je
předběžné načítání vypnuto, uvažujete-li o spotřebě energie u laptopů). A
pokud systém potřebuje RAM, která byla těmi načtenými stránkami chybně
zaplněna a není-li k nim přistupováno, budou to první, co se vyhodí - bez
jakéhokoliv I/O, protože jsou na úplném konci neaktivního LRU seznamu a
kopii mají uloženou."
SCSI ID
28. bře, originál
Zajímavé vlákno na LKML začalo patchem, který chtěl přesunout IOCTL
volání používané k získání SCSI ID zařízení z blokové vrstvy do SCSI
subsystému. Linus Torvalds poměrně vehementně argumentoval, že neexistuje
nic, čemu by se říkalo SCSI ID, "Nechte toho. Měli
bychom to ioctl zrušit, ne se pokoušet, aby vypadalo smysluplně. Takový
způsob hledání SCSI zařízení nedává smysl. A skutečnost, že někteří lidi
kolem SCSI si to myslí, na tom nic nemění." Podobně vzrušená diskuze
se o tomto tématu rozběhla v konferenci několikrát, argumenty přicházely z
obou stran. V zatím nejnovějším vlákně Linus vysvětloval:
"Byla to stupidní myšlenka i v 80. letech. Od té doby je čím dál
stupidnější. V těch 80. letech byla alespoň _omluvitelná_. Bylo přijatelné
si myslet, že řadiče lze prostě očíslovat. A bylo to snadné, a protože
tehdy byly hotplug řadiče typu "obsluha zastrčí", ne jako ty moderní
"magicky se objeví", tak to fungovalo a čísla řadičů něco znamenala
(přestože se měnila, když člověk věci zpřeházel, ale to se dalo
očekávat).
"Dneska už není možné řadiče jakýmkoliv rozumným způsobem číslovat.
Neřekl bych, že to vůbec kdy bylo možné, ale přinejmenším bylo u
statického hardwaru jakékoliv náhodné číslování stejně užitečné jako každé
jiné."
Související články
Odkazy a zdroje
Další články z této rubriky
Diskuse k tomuto článku
10.4.2006 00:10
Radek Podgorny | skóre: 16
Re: Jaderné noviny - 29. 3. 2006
10.4.2006 16:57
Pavel Beníšek | skóre: 27
Re: Jaderné noviny - 29. 3. 2006
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
.
10.4.2006 14:09
Nikola Ciprich | skóre: 23
| blog: NiX_blog
| Palkovice
10.4.2006 16:57
