Portál AbcLinuxu, 19. dubna 2024 15:37
Jaderné noviny - 1. 8. 2007
Články
-
Jaderné noviny - 1. 8. 2007
Aktuální verze jádra: 2.6.23-rc1. Citáty týdne: Ingo Molnar, Arjan van de Ven, Len Brown. Zpráva o stavu suspend a hibernace. Regulace využití paměti v kontejnerech. i386 a x86_64: zase spolu? Historické verze jádra v repozitáři gitu.
Obsah
Aktuální verze jádra: 2.6.23-rc1
link
Aktuální předverze je i nadále 2.6.23-rc1, během minulého týdne nebyly vydány žádné nové předverze. Do hlavního git repozitáře však bylo od vydání -rc1 přesto začleněno přes 500 patchů a -rc2 už má zpoždění. Šlo většinou o opravy, ale přibyla i "literární" dokumentace k Lguest, mechanismus, pomocí kterého může jaderný kód požádat o upozornění, má-li na něj být uplatněna preempce, nové konfigurační možnosti pro softwarové uspání a hibernaci a podpora framebufferu u AMD Geode LX. Kromě toho byla odstraněna podpora procesorů SuperH sh73180 a 7300 a zmizel i celý port pro arm26. Trochu změněno bylo API pro kontrolu zahlcení TCP.
Aktuální verze -mm stromu je 2.6.23-rc1-mm2. Mezi nedávné změny patří podpora více cílů netconsole, subsystém pro desku Sonics Silicon a několik oprav reiser4.
Starší jádra: 2.6.16.53 bylo vydáno 25. července s asi desítkou oprav. 2.4.35 bylo vydáno 26. července s několika backportovanými ovladači a pár opravami.
Citáty týdne: Ingo Molnar, Arjan van de Ven, Len Brown
link
Tty vrstva je jedním z mála míst v jádře, kterých se děsně bojím.
-- Ingo Molnar
Byl bych raději, kdyby lidem méně záleželo na tom, kdo napsal kód, který byl nakonec začleněn, a více na problému, který se tím vyřešil... Když někomu záleží na desktopu, měl by být rád, že je teď plánovač o hodně lepší - díky konkurenci dvou plánovačů, které se ve většině aspektů lišily jen o vlásek.
-- Arjan van de Ven
Tahle specifikace říká, že systémy, které se neumí automaticky po 15 minutách nečinnosti uspat, tu nálepku _nemohou_ získat. Nebude nálepka, nebudou ani vládní zakázky na počítače. Pokud Linux nedokáže poskytnout STR (Suspend-to-RAM, uspání do RAM), které by bylo funkční, běžně nasazované a ve výchozím nastavení zapnuté, tak budou mít naše plány na ovládnutí světa vážnou trhlinu.
-- Len Brown
Zpráva o stavu suspend a hibernace
link
Rafael Wysocki, aktuální správce jaderného kódu pro uspávání a hibernaci, sestavil dlouhý dokument popisující současný stav. Tento dokument je koncipován jako úvod do aktuálního (tj. v jádře 2.6.23-rc1) designu kódu, který implementuje uspávání (suspend-to-RAM a standby [uspání do RAM a pohotovostní režim]) a hibernaci. Stav, známé problémy a vývojové plány. Je to na dlouhé čtení, ale pokud vás tento subsystém zajímá, tak to stojí za to.
Regulace využití paměti v kontejnerech
link
"Kontejnery" je termín označující odlehčený přístup k virtualizaci, při kterém běží všechny hostované systémy na jádře hostitele (na rozdíl od běhu s vlastními jádry při využití celého virtuálního stroje). Kontejnerová technika bývá při běhu efektivnější, ale jsou s ní spojeny specifické problémy; protože všechny kontejnery běží na stejném jádře, je potřeba vytvořit celou řadu interních bariér, které dají každému kontejneru iluzi, že má celý stroj pro sebe. Přidávání těchto bariér do linuxového jádra probíhá už několik let - různé projekty, které se v této oblasti angažují, připravují sadu rozhraní, kterou by mohli všichni používat.
Důležitou součástí kompletní implementace kontejnerů je regulace zdrojů; bylo by těžké udržovat iluzi o samostatném stroji pro každý kontejner, kdyby jeden z těchto kontejnerů zahlcoval celý systém. Rozsáhlým patchům pro správu zdrojů se v minulosti dostalo chladného přijetí, ale korektní implementace založená na systému kontejnerů procesů by mohla být do jádra přijata. Skupinové plánování pro CFS je možné brát jako jeden z druhů správy zdrojů založených na kontejnerech. Ale je potřeba se postarat o mnohem více věcí než jen procesor.
Jedním z nejžádanějších zdrojů na mnoha systémech je paměť. Kontejner, který by rostl bez omezení a vytlačil ostatní kontejnery do swapu, by v konferenci linux-kernel nebyl moc populární. Ve snaze předejít takovým nepříjemnostem pracují Balbir Singh a Pavel Emeljanov na implementaci kontejnerového regulátoru paměti. Patch je teď ve čtvrté verzi.
Patch začíná jednoduchou abstrakcí: "počítadlo zdrojů" [resource counter], které je určeno pro použití s kontejnery. Bude fungovat s kterýmkoliv zdrojem, u kterého lze popsat obyčejnými celými čísly maximální povolené a aktuální využití. K dispozici jsou metody, které umožňují připojení těchto počítadel ke kontejnerovým objektům, a které zároveň umožní dotazování a nastavování z uživatelského prostoru.
Počítadla poslouží k monitorování využití paměti každého kontejneru. Využití paměti lze brát jako aktuální residentní sadu: počet residentních stránek, které si procesy v kontejnerech namapovaly do svých virtuálních adresních prostorů. Na rozdíl od některých dřívějších patchů se tento reguláror snaží sledovat i využití stránkové keše. Takže program, který je velmi malý, ale dává spoustu dat ze souborového systému do stránkové keše, bude vypadat, že používá hodně paměti.
Aby mohl sledovat využití stránek jednotlivými kontejnery, musí se regulátor napojit na nízkoúrovňovou stránkovou keš a kód pro vracení stránek. Také potřebuje místo pro ukládání informací o tom, ke kterému kontejneru je která stránka počítána. Proto byla vytvořena nová struktura:
struct meta_page {
struct list_head lru;
struct page *page;
struct mem_container *mem_container;
atomic_t ref_cnt;
};
Globální správu paměti mají na starosti dva seznamy řazené podle pravidla least-recently-used (LRU) [nejvíce dávno používané], protože se předpokládá, že stránky, které nebyly dlouho používány, bude nejbezpečnější odstranit, když paměť dochází. Když však přibudou kontejnery, přestává globální správa stačit. Takže struktura meta_page umožňuje vložit každou stránku na samostatné LRU seznamy pro jednotlivé kontejnery. Když pak proces běžící v kontejneru přibere stránku a způsobí, že kontejner narazí na svůj paměťový limit, musí jádro - pokud chce tento limit dodržet - vyřadit některé jiné stránky daného kontejneru. Pokud k takové situaci dojde, prohlédne se kontejnerový LRU seznam, aby se našly stránky patřící kontejneru, které lze vrátit, aniž by se musela procházet paměť, která s daným kontejnerem nesouvisí.
Struktura page v globální paměťové mapě má přidaný ukazatel na příslušnou strukturu meta_page. Přibyl také nový příznak stránky, který tu strukturu může uzamknout. Pro jaderné stránky žádná struktura meta_page není, ale vytvoří se jedna pro každou stránku uživatelského prostoru nebo stránku keše stránek - i pro procesy, které nebyly zařazeny do kontejneru (takové procesy jsou automaticky umístěny do výchozího, globálního kontejneru). Regulátor paměti má tedy značnou režii - pět nových ukazatelů (jeden ve struct page, čtyři ve struct meta_page) a jeden atomic_t pro každou aktivní stránku v systému - nic příjemného.
S tímto mechanismem může jádro implementovat základní kontrolu nad využíváním paměti v kontejnerech. Zbývá jeden menší problém: co když se jádru nepodaří stlačit paměť kontejneru pod limit? V takovém případě nastoupí obávaný out-of-memory killer [zabiják procesů při nedostatku paměti]; k dispozici je speciální verze OOM zabijáka, která své řádění omezuje na jediný kontejner. Některé procesy tedy nepřežijí, ale ostatní kontejnery by měly zůstat nedotknuty.
Jeden za zajímavých aspektů problému, který pravděpodobně není zcela dořešen, jsou stránky používané procesy z několika kontejnerů. Do této kategorie spadají mnohé sdílené knihovny, ale mohlo by tam patřit i využívání stránkové keše. Stávající kód přičte stránku prvnímu kontejneru, který ji používá. Pokud by byla stránka vybrána k odstranění, došlo by k odmapování ze všech kontejnerů; pokud pak tu stránku přivolá [faults in] jiný kontejner, bude mu od té chvíle připočítána. Takže za nějakou dobu by vracecí mechanismus mohl způsobit, že by se připočítávání sdílených stránek mohlo rozdělit mezi všechny kontejnery v systému - nebo by se hromadilo v jediném neomezeném kontejneru, pokud by takový existoval. Bude potřeba mechanismus pečlivě otestovat s různými zátěžemi, aby se dalo určit, jestli nebude mít za následek opravdové problémy. A vypadá to, že s testováním se sotva začalo.
Prozatím máme regulátor paměti, který, jak se zdá, zvládá základní věci, což je dobrý začátek. Určitě je vhodný pro použití s kontejnery, ale možná se projeví jako užitečný i v jiných situacích. Administrátor systému třeba nemusí chtít plnohodnotné kontejnery, ale mohlo by se mu hodit držet na uzdě paměťově náročné procesy (updatedb, zálohování atd.). Uživatelé by mohli, dejme tomu, přiškrtit OpenOffice.org, aby z paměti nevytlačilo všechny ostatní zajímavé věci.
i386 a x86_64: zase spolu?
link
Adresář arch ve zdrojových kódech jádra obsahuje všechen kód specifický pro jednotlivé architektury. Kódu je tam spousta, i když se vývojářská komunita už roky snaží při každé příležitosti věci zobecňovat. V současné době podporuje Linux 26 architektur, které tam mají své zastoupení, přičemž mnohé z nich obsahují několik podadresářů. Dvě z těchto architektur jsou i386 (původní architektura Linuxu) a x86_64 - 64bitový velký brácha i386. Tyto dvě architektury toho mají dost společného a usiluje se o sdílení kódu, kdykoliv to je možné. Přesto však zdrojové stromy zůstávají odlišné.
Podle některých vývojářů způsobuje rozdělení architektur problémy. Oprava chyby, kterou je nutné provést v jednom, se často týká i druhého - není však zaručeno, že oprava opravdu na obou místech proběhne. I nové funkce musí být přidávány dvakrát. Je poměrně snadné způsobit problémy v jedné architektuře, zatímco pracujete na té druhé. Vývojáři pracující na projektech specifických pro jednotlivé architektury - často se mluví o virtualizaci - nakonec mají více práce, když musejí držet krok se dvěma velmi příbuznými stromy. V reakci na podobné stížnosti byly v jádře 2.6.15 sjednoceny stromy 32bitové a 64bitové architektury PowerPC - a panuje všeobecná shoda, že to byl rozumný krok. U variant x86 však zatím ke spojení nedošlo.
Možná se však blíží změna: Thomas Gleixner a Ingo Molnar nedávno představili patch pro sloučení obou architektur. Ten patch je obrovský: má přes 9 MB a mění 1764 souborů. Je tolik vázán na aktuální stav jádra, že jej lze aplikovat jen na jediný konkrétní bod v git repozitáři. Není to však patch, který by měl být začleněn do hlavního jádra; jeho účelem je pouze ukázat, jak by vypadal výsledek. Pokud nakonec dojde na začleňování, provede se to jinak:
Dalším krokem bude vygenerování plně funkčního postupného přechodu z aktuálního kódu na kompletní strom arch/x86, který bude možné rozebrat a zkontrolovat. Výsledkem bude přibližně 1000 - 2000 commitů.
To je také trochu děsivé, takže vývojáři, kteří na věci pracují, se všemožně snažili, aby šlo změny začlenit bez obav. Sloučení nebudou doprovázet žádné úpravy kódu: ze stromu bude možné sestavit přesně stejné obrazy jádra před i po sloučení.
Patch vytváří architekturu nazývanou x86 a přesouvá do ní všechno ze stávajících dvou architektur. V těch několika případech, ve kterých mají obě architektury identickou kopii nějakého souboru, je v novém stromě vytvořen jen jediný soubor. Častěji však mívají stejně pojmenované soubory na stejných místech, jejichž obsah se liší. To jsou pak do nového stromu přesunuty oba soubory s příponami _32 nebo _64. Obě architektury například obsahují kernel/ioport.c; nová architektura x86 má ioport_32.c a ioport_64.c. Nakonec se používá hrstka triků, aby se zajistilo, že bude pro každou cílovou architekturu zkompilován ten správný soubor.
V mnoha případech (jestli ne ve většině) je v obou souborech hodně společného kódu - ten je tam však zatím ponechán. V tuto chvíli jde o to, aby byly oba stromy spojeny bez vlivu na výsledné jádro; to je patrně jediný způsob, jak zařídit přijetí tak velké změny. Jakmile dojde ke sloučení, začnou být příležitosti pro odstraňování duplicitního kódu lépe vidět - soubory budu většinou hned vedle sebe. Lze si představit armádu údržbářů, která se na tu práci vrhne - většinou by mělo jít o přímočaré změny. Až by to bylo hotové, měli bychom novou a naleštěnou sloučenou architekturu bez duplicitního kódu a všichni by se mohli radovat.
A nebo také ne. Andi Kleen vyjádřil svůj nesouhlas s takovou změnou:
Myslím, že to není dobrý nápad, protože bychom se nikdy nemohli zbavit starého smetí. Dle mého ne zcela skromného názoru je arch/x86_64 v mnoha směrech výrazně čistší než arch/i386 a já bych rád, aby to tak zůstalo. Obecně je také mnohem snazší hackovat na arch/x86_64 než na arch/i386, protože je možné jednodušeji testovat na regrese a vůbec je potřeba se starat o daleko méně nepořádku. A nevím, jak se toho u i386 zbavit - kromě vyházení těch starých věcí.
Andi, coby správce architektur i386 a x86_64, má v této debatě docela silné slovo. Jeho hlavním argumentem je, že rozdělení architektur umožňuje udržení množství starších věcí v i386 - což odpovídá běžné praxi při správě jaderného kódu. Kód, který podporuje pouze novější hardware, bývá mnohem čistší než kód, který se musí potýkat i se staršími kousky - ale odstraňovat podporu stále používaného hardwaru není možné. Takže je raději pro novější věci vytvořen nový subsystém, přičemž starší kód může být spravován samostatně, dokud se nevytratí. Klasickým příkladem je způsob implementace SATA ve vlastním subsystému, místo aby byla podpora přidána do kódu IDE. Andi, společně s několika dalšími vývojáři, tvrdí, že by podpora rodiny procesorů x86 měla být řešena stejně.
Vypadá to však, že většina prvotních účastníků diskuze s Andim nesouhlasí. Argumentují tím, že na rozdíl od IDE se 32bitová architektura v dohledné době nevytratí. Množství podivnůstek, které jsou skutečně pouze v i386, je považováno za poměrně malé. Linus tvrdí, že je snazší se starat o starší kód, když je součástí sdíleného stromu, než když je odstrčen do kouta. Podle debaty, která následovala po prvním oznámení, se zdá, že většina lidí považuje sjednocení stromů za správný postup.
Objevilo se i pár návrhů, aby byl patch zařazen už do 2.6.23, ale asi bude lepší, když to tak nedopadne. Ve 2.6.23 už je věcí hodně a tento patch je nový. Když se mu nechá jeden vývojový cyklus na práci, jen to pomůže. Kromě toho ještě nevznikl repozitář s těmi 1000 nebo kolika samostatnými commity.
Nejpodstatnější však je, že ještě neproběhla skutečná diskuze o sloučení. Přepracovat dvě architektury do jedné přes stížnosti jejich správce by hraničilo s nepřátelským převzetím kódu. Správci nemají absolutní vetovací pravomoce, ale ignorovat správce při začleňování takhle velkého patche by nemělo být tak snadné. Takže vývojáře sjednocené architektury x86 čeká ještě jeden velký problém: hezky vyřešili technické otázky a přesvědčili většinu vývojářské komunity, ale je v zájmu všech, aby našli způsob, jak přesvědčit i správce kódu, se kterým pracují.
Následující obsah je © KernelTrap
Historické verze jádra v repozitáři gitu
link
25. črc, originál
V nedávné diskuzi na LKML se mluvilo o importu kompletní historie linuxového jádra do git repozitáře. Linus Torvalds poznamenal: Vlastně jsem se o něco podobného pokoušel s BitKeeperem někdy na počátku aféry se SCO. Bylo dost náročné hledat všechny staré stromy a patche - jsou v různých formátech a na některé není spoleh. Uvažoval jsem o znovuvytvoření opravdu staré historie v gitu, ale i to je hodně práce. A pochopitelně to není moc užitečné - jen zajímavé z archeologického hlediska. Spousta informací o raných jádrech je shromážděna na oldlinux.org a Linus už z BK do gitu importoval kompletní historii od 2.5.0 do 2.6.12-rc2. Později mluvil o tom, proč je pro sestavování historie vhodnější git než BK:
Dobrá zpráva je, že git by se na vytváření historie hodil daleko více, protože můžete prostě importovat náhodné stromy a pak historii poskládat zpětně - zkusit je všechny poslepovat dohromady. A když najdete nový strom, prostě ho přilepíte místo jiného. To bylo s BK velmi složité (a BK nebyl obecně moc ku pomoci, když chtěl člověk udržovat několik nezávislých stromů, a nešlo s ním historii předělávat a udržovat několik verzí).
Související články
Odkazy a zdroje
Další články z této rubriky
Diskuse k tomuto článku
9.8.2007 09:07
Peto_MiG
Re: Jaderné noviny - 1. 8. 2007
10.8.2007 11:00
valesek | skóre: 10
Re: Jaderné noviny - 1. 8. 2007
10.8.2007 14:54
Jiri
IDE se vytrati...
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
, tak bych chtel autorovi vyjadrit diky za jeho vytrvalou praci. Bez nej bych s mou anglictinou o novinkach v kernelu nic nevedel.
Jeste jednou: DIKY
9.8.2007 09:31
9.8.2007 10:48
Honza Balák | skóre: 23
| blog: Jaxův linuxový zápisník
| Předklášteří
9.8.2007 15:23
9.8.2007 09:03
9.8.2007 11:47
9.8.2007 16:21
10.8.2007 16:44