Jaderné noviny – 4. 8. 2010: Co bude v jádře 2.6.36

26. 8. 2010 | Jirka Bourek | Jaderné noviny | 3730×

Aktuální verze jádra: 2.6.35. Citáty týdne: Sean Michael Kerner, Hugh Dickins, Chris Mason. AppArmor bude začleněn do 2.6.36. Yama: Ne tak rychle. Android a správa napájení. Začleňovací okno 2.6.36, část první. Teplota dat v Btrfs.

Obsah

• Aktuální verze jádra: 2.6.35
• Citáty týdne: Sean Michael Kerner, Hugh Dickins, Chris Mason
• AppArmor bude začleněn do 2.6.36
• Yama: Ne tak rychle
• Android a správa napájení
• Začleňovací okno 2.6.36, část první
• Teplota dat v Btrfs

Aktuální verze jádra: 2.6.35

Jádro 2.6.35 bylo vydáno 2. srpna. Relativně dlouhé oznámení obsahuje nějaké úvahy o tomto vývojovém cyklu (Linus je spokojený s tím, jak fungoval) a obavy ze stavu linux-next, který míří do 2.6.36. Mezi nejvýraznější vlastnosti 2.6.35 patří směrování přijímaných paketů a směrování toku přijímaných dat, shlukování využité paměti, podpora přímého I/O pro Btrfs a obvyklá hromádka nových ovladačů. Jako vždycky lze spoustu detailů nalézt na excelentní stránce o 2.6.35 na KernelNewbies.

Aktualizace stabilních jader: Venku jsou aktualizace 2.6.27.49, 2.6.32.17, 2.6.33.7 a 2.6.34.2; všechny jako obvykle obsahují důležité opravy. 2.6.33.7 je poslední aktualizace 2.6.33, uživatelé by tady měli uvažovat o přechodu na vyšší verzi; Greg doporučuje 2.6.35, protože 2.6.34 se už o moc déle udržovat nebude.

Citáty týdne: Sean Michael Kerner, Hugh Dickins, Chris Mason

Vydání Linuxu 2.6.35 je významné také tím, že je to první verze jádra, ve které se Torvalds specificky pokusil omezit množství změn provedených během vývoje, aby tím pomohl omezit rostoucí velikost a složitost aktualizací jádra.

-- Sean Michael Kerner, LinuxPlanet

Takže mezi vytvořením snímku a skutečnou hibernací zde máme dva paralelní vesmíry, jeden je zmrazen v obrazu a druhý ho zapisuje do swapu: S tím nebezpečím, že ten druhý (který brzy zemře) zavede do toho prvního kritické nekonzistence tak, že vloží stránky na místo ve swapu, které z něj bylo nevinně realokováno. (Omluvte mě, jdu napsat filmový scénář.)

-- Hugh Dickins

Lituji toho, že jsem do původního kódu bariér vložil řazení… rozhodně to tenkrát pomohlo reiserfs, ale smrdí to magií a voodoo. Když se to pokazí, všimneme si toho jenom v 0,000000001 % případů, a to pouze v případě, že někdo nahlásí náhodné poškození, které slepě hodíme buď na Axboea, nebo na disk.

-- Chris Mason

AppArmor bude začleněn do 2.6.36

Jsou to více než čtyři roky od doby, kdy Jaderné noviny poprvé psaly o bezpečnostním modulu AppArmor a opozici vůči jeho začlenění do hlavní řady. Během té doby došlo k mnoha diskuzím o bezpečnosti založené na cestách [pathname], o hodnotě toho mít víc bezpečnostních modulů a k dalším; AppArmor se mezitím vytratil z dohledu. Vývojář z Canonicalu John Johansen tento modul ale sebral a pracoval na jeho začlenění. Nejnovější zpráva „co se chystá“ od správce zabezpečení Jamese Morrise nyní ukazuje, že AppArmor byl zařazen do fronty pro příští začleňovací okno (bezpečnostní modul „Yama“ od Canonicalu je v plánu také). Pokud se neobjeví opozice na poslední chvíli, měl by to být konec tohoto dlouhého příběhu.

Celý článek na LWN.net.

Yama: Ne tak rychle

napsal Jonathan Corbet, 3. srpna 2010

Náhled subsystému zabezpečení 2.6.36 od Jamese Morrise mezi jinými obsahoval i bezpečnostní modul Yama, který obsahuje mnoho s bezpečností spojených změn od Canonicalu. James tento náhled později aktualizoval a řekl:

Věci ohledně Yama vezmu z 2.6.36 zpět – Christoph tomu dal mimo konferenci nack.

Sestřelit něco mimo konferenci vždycky vyvolá rozruch, ale Christoph (Hellwig) rychle své námitky zveřejnil. Řekl:

Jak bylo několikrát zmíněno v minulé diskuzi, přesun špatného kódu do LSM ten kód magicky neopraví. Ve skutečnosti YAMA není žádnou (polo-)koherentní bezpečnostní politikou jako Selinux, smack nebo podobné, je to jenom náhodná sada hacků, které se nedostaly přes správce subsystémů.

Christoph by byl podle všeho raději, kdyby tyto změny šly přímo do relevantních subsystémů a nevkládaly se do samostatného bezpečnostního modulu. Problém je ovšem v tom, že takhle autor modulu Yama Kees Cook začal; rozhodně mu bylo řečeno, že vkládání změn spojených s bezpečností přímo do kódu VFS a ptrace() je nežádoucí. Tenkrát dostal radu, aby své změny vložil do bezpečnostního modulu, kde je bude moci zbytek světa ignorovat. Dokonce i Christoph v červnu navrhoval tento přístup.

Námitka „nekoherentní bezpečnostní model“ byla k slyšení i z jiných směrů. Podle Valdise Kletniekse:

Jinými slovy – jestliže chceš LSM, musíš mít dostatek vlastností, abys pokryl všechno, nejenom to, co si vybereš.

Zdá se, že někteří vývojáři by nechtěli úpravy spojené s bezpečností nahromaděné v modulu bez politiky nad ním. Také se objevila obvyklá tvrzení, že všeho, co dělá Yama, by se dalo dosáhnout pomocí SELinuxu, i když Kees podle všeho nesouhlasí.

Toto odmítnutí ponechává Keese v obtížné situaci: Snaží se dostat své změny do upstreamu (což je něco, za co je kritizován jeho zaměstnavatel, protože to nedělá), ale nemá žádný zjevný způsob, jak je začlenit. Možná ale bude stačit jenom trocha trpělivosti. Nové bezpečnostní moduly se podle všeho vždy setkají s opozicí, ale s trochou vytrvalosti nakonec bývají začleněny.

Android a správa napájení

napsal Jonathan Corbet, 3. srpna 2010

Zdá se, že Paul McKenney nyní pracuje pro projekt Linaro, což ho přivedlo k novému zájmu o správu napájení. Rozhodl se, že začne hlasitě, a pokusil se shrnout diskuzi o blokování uspání s cílem pochopit, jaké jsou potřeby Androidu. Není potřeba říkat, že tím nakopl další dlouhou diskuzi, která vrhla postoje hráčů do nového světla.

S přílišným zjednodušením: Jedna strana podle všeho věří, že správu napájení (a hlavně špatně se chovající aplikace) je potřeba řešit tím, že se na špatně fungující aplikace ukáže a opraví se (nebo se vytvoří tlak na to, aby byly opraveny) jedna po druhé. To je přístup, který používají vývojáři jako Arjan van de Ven, který s velkým úspěchem vytvořil nástroj PowerTop. Druhá strana tlačí na obecnější řešení; Paul popisuje rozdílné postoje takto:

Souhlasím s tím, že během posledních čtyř let došlo k velkému pokroku. Doba běhu mého laptopu na baterii se výrazně zvýšila a přibližně polovina z tohoto zvýšení je díky změnám v softwaru. Když si to sečteme za všechna PC a laptopy, rozhodně se to nasčítá na významné a cenné úspory.

Takže ano, vedli jste si dobře.

Spoléhat se však na opravování aplikace po aplikaci, i když je to zatím dobré, přináší obavy do budoucna. Obavy mám, protože historie počítačů nebyla přívětivá k těm, kterým se nedařilo dostatečně automatizovat. Lidi od Androidu nám nabídli jeden způsob, jak automatizovat efektivitu využívání energie. Možná jsou lepší přístupy, ale jejich přístup si přinejmenším zaslouží spravedlivý proces – a nikdo, kdo četl nedávnou diskuzi na LKML, si ji rozhodně nemůže splést s čímkoliv, co by spravedlivý proces jenom trochu připomínalo.

Prozatím se konverzace k přístupu Androidu nevrátila; je stále zaměřena na potřeby a na to, jestli přístup ke správě napájení „praštit špatnou aplikaci do hlavy“ bude dlouhodobě dostačující. Je velká šance, že Paul v blízké budoucnosti zašle aktualizovanou verzi svého popisu potřeb; pak by mohlo dojít ke klidné diskuzi o tom, jak tyto potřeby naplnit.

Začleňovací okno 2.6.36, část první

napsal Jonathan Corbet, 4. srpna 2010

Začleňovací okno 2.6.36 začalo poměrně pomalu; Linus možná trávil příliš mnoho času u kávovaru a příliš málo u klávesnice. Věci se ale 4. srpna daly do pohybu, v době psaní tohoto článku bylo do hlavní řady začleněno 2600 patchů. Zde je shrnutí toho, co bylo zatím k vidění.

Mezi změny viditelné pro uživatele patří:

• Souborový systém 9p získal podporu pro rozšířené atributy a novou, pro Linux specifickou variantu protokolu 9p2000 nazvanou 9p2000.L.

• Souborový systém CIFS nyní může používat FS-Cache a ukládat si lokální kopie souborů kvůli výkonnosti.

• Bezpečnostní modul TOMOYO má nový „režim pro interaktivní vynucování“, který správci systému umožňuje povolit za běhu porušení politiky. Cílem je pomoci při instalaci aktualizací aplikací (které vyžadují změny politiky) na běžících produkčních systémech.

• Konečně byl začleněn bezpečnostní modul AppArmor.

• Byl začleněn mechanismus wakeup_count Rafaela Wysockiho. Cílem této vlastnosti je umožnit uspání systému bez obav, že dojde k souběhům s probouzecími událostmi; má vyřešit část problémů, které řeší blokování uspání.

• Podpora pro API infračervených ovladačů LIRC byla začleněna společně s dlouhým seznamem LIRC ovladačů. LIRC je jeden z větších kusů kódu mimo strom, který dodává mnoho distributorů, takže toto začlenění by mělo pomoci přiblížit distribuční jádra k hlavní řadě.

• Nové ovladače:

  • Desky a systémy:

    • moduly Bluewater Systems Snapper 9260/9G20,
    • tenké klienty HP t5325,
    • systémy založené na NXP Semiconductor LPC32xx,
    • moduly Eukrea CPUIMX51 a CPUIMX35.

  • Vstupní zařízení:

    • dotykové obrazovky Atmel QT602240 I2C,
    • trojosé digitální akcelerometry Analog Devices ADXL34x,
    • dotykové obrazovky Cypress cy8ctmg110.

  • Různé:

    • znakové LCD displeje ARM Ltd.,
    • GPIO linky HTC Dream (telefon G1),
    • řadiče Intel „pro inteligentní sdílení energie“.

  • Sítování:

    • řadiče Freescale Flexcan CAN,
    • rozhraní ESD USB/2 CAN/USB,
    • gigabitové a 10gigabitové ethernetové adaptéry založené na Chelsio T4 s virtuálními funkcemi PCI-E SR-IOV,
    • protokolové ovladače CAIF na slave SPI rozhraních.

  • Video4Linux:

    • rozhraní pro kamerové senzory i.MX27/i.MX25,
    • USB kamery založené na SunPlus SPCA1528,
    • USB kamery založené na SQ Technologies SQ930X,
    • infračervené vysílače-přijímače pro Windows Media Center Edition eHome,
    • video enginy Freescale VIU.

Mezi změny viditelné pro vývojáře jádra patří:

• Architektura ARM ztratila podporu pro paměťový model „discontigmem“; očekává se, že nyní již všichni používají sparsemem. ARM také přešlo od starého alokátoru bootmem k memblock (dříve LMB) a přibyla v něm podpora pro GCC volbu -fstack-protector

• Ze souborového systému byly vyhozeny háčky pro DMAPI, což naznačuje, že vývojáři XFS neočekávají, že by někdy na této úrovni vznikla podpora pro hierarchická úložiště.

• API PM_QOS se zase změnilo; požadavky na kvalitu služby se nyní přidávají voláním:

  void pm_qos_add_request(struct pm_qos_request_list *request,
                          int pm_qos_class, s32 value);

  Největší změna je, že strukturu request nyní musí alokovat volající; to trochu přesouvá práci, ale umožňuje to tuto funkci zavolat v atomickém kontextu.

Lze očekávat, že začleňovací okno zůstane otevřené přibližně do 15. srpna, pokud se Linus nerozhodne překvapit vývojáře a zkrátit ho.

Teplota dat v Btrfs

napsal Jonathan Corbet, 3. srpna 2010

Linux se, stejně jako většina ostatních operačních systémů, snaží uchovávat data, ke kterým se často přistupuje, v hlavní paměti. Cena načítání stránky z disku je značná, takže každá operace, kterou lze eliminovat uchováním dat v rychlejším úložišti, znamená výkonnostní zisk. V nedávné době byl zájem o přidávání více úrovní cache; výsledkem jsou patche jako bcache, Cleancache/Frontswap, zcache a další. Nejnovější příspěvek v této oblasti je sada patchů zaměřená na vytvoření víceúrovňového cachování v souborovém systému Btrfs.

Patche, které zaslal Ben Chociej, nejsou v současnosti kompletní řešení. Tento kód pouze přidává infrastrukturu, která je potřeba k rozlišení toho, která data jsou v souborovém systému „horká“; v blízké budoucnosti přijde další část, která umožní tyto informace využít a rozhodnout, která data by bylo přínosné cachovat na rychlejším médiu – například na úložišti bez rotujících částí. Povaha Btrfs s kopírováním při zápisu [copy-on-write] společně se zabudovaným kódem pro správu svazků by měla implementaci této funkce značně zjednodušit. To zjistíme během „pár týdnů“, kdy byly slíbeny první patche; mezitím máme relativně zajímavé nástroje, na které se můžeme podívat.

Patche fungují tak, že se zaháčkují do několika míst v Btrfs, kde se zahajují I/O operace. V každém z těchto míst se objevuje volání:

void btrfs_update_freqs(struct inode *inode, u64 start, u64 len,
                        int create);

inode je inode souboru, na kterém se pracuje, start je počáteční pozice (v bytech), len je počet bytů, které se přenášejí, a trochu matoucí parametr create je nenulový, pokud se jedná o zápisovou operaci. Tato funkce udržuje dva červeno-černé stromy; první platí pro celý souborový systém a sleduje „nejteplejší“ inody. Pro každý inode existuje další strom, který sleduje nejteplejší části souboru. Pro každý strom btrfs_update_freqs() aktualizuje uložené parametry předanými hodnotami.

Kód sleduje šest nezávislých parametrů: počet čtení, klouzavý průměr časů mezi čteními a čas od posledního čtení; stejné parametry i pro zápisy. Tyto informace se nakonec předají kouzlu nazvanému btrfs_get_temp(), které tato čísla převaří do jediné hodnoty „teplota“. Autor článku by zde rád jednoduše poskytl rovnici, která se používá, ale ta není tak jednoduchá – obsahuje spoustu triků s magickými konstantami a různá opatření proti přetečení. Ti, kteří ji chtějí znát přesně, si mohou přečíst zdrojové kódy btrfs_get_temp().

Sada patchů přidává tři nové ioctl() operace. Informace o teplotě specifického souboru lze získat pomocí BTRFS_IOC_GET_HEAT_INFO. Také jsou zde BTRFS_IOC_GET_HEAT_OPTS a BTRFS_IOC_SET_HEAT_OPTS pro dotazování a nastavování teploty a (do budoucna) migraci dat založenou na naměřených teplotách. Pro ty, kdo by se chtěli podívat na všechna data nasbíraná těmito nástroji, je zde i rozhraní pro debugfs.

K této sadě patchů se neobjevilo příliš mnoho reakcí. Nejvýznamnější stížnost šlo víceméně předvídat: Tyto schopnosti vypadají jako něco, co by bylo užitečné pro mnoho dalších souborových systémů, takže implementovat je pro Btrfs vypadá jako práce na špatné úrovni. Vrstva virtuálního souborového systému (VFS) může snadno sledovat I/O operace a zabývat se správou těchto dat. VFS by také možná mohla použít tato data a lépe se podle nich rozhodovat o tom, které stránky nechat v cache stránek. Pokud budou ale tato data uzamčena v Btrfs, VFS vrstva je nebude moci použít a nebudou z nich moci těžit žádné jiné souborové systémy.

Reakce na tuto stížnost je, že jenom Btrfs má potřebnou podporu pro více zařízení [multiple device], která je zapotřebí k využití těchto dat. Podle Davea Chinnera toto ospravedlnění není přesvědčivé, řekl:

Proč to vůbec potřebuje více zařízení v souborovém systému? Jediné, co souborový systém potřebuje vědět, je relativní rychlost oblastí v adresovém prostoru jeho bloků, a musí se mu poskytnout nápověda k alokacím.

Mezi těmi, kdo chtějí přidávat vlastnosti do specifických souborových systémů, a těmi, kdo by je měli raději na úrovni VFS, často vzniká určité napětí. Obecné pravidlo je, že šířeji používané vlastnosti je lepší zabudovat do VFS, protože tam je možné je častěji používat a jsou tak lépe pod dohledem. Implementace v jednom souborovém systému nicméně může často sloužit jako vzorový příklad a jako místo, kde se přijde na důležité poznatky. Tím vším chce autor říci, že „sledování horkých dat“ se do jádra pravděpodobně dostane, ale není jasné, jestli v té době bude připomínat současné patche, nebo ne.

       

Komentáře

[Bedňa]

Neviem tento týždeň sa mi zdal hrozne dlhý, odprísahal by som, že JN vyšli až po dvoch týždňoch, hoci viem že to nieje pravda :) Super článok, JN sú jednotka na Ábičku.

[Robert Krátký]

Vlastně vyšly po 2 týdnech - ne vždy se podaří to stihnout.

[miso]

Dik za stale cerstve info o jadre. A za tvoju chut nas stale informovat

[none]

Roky jsem JN necetl, nezajimaly me a taky jsem mnoha vecem nerozumnel. A to presto, ze je to tak pekne napsane a predzvykane. Snad konecne diky memu 'profesnimu rozvoji' a praci, pri ktere na to mam cas jsem se k tomu vratil a kazdy tyden JN prelouskam. Je pravda, ze i ted plno vecem nerozumim, ale uz se zacinam chytat :). Snazim se i cist na kernelnewbies.org, abych to mel komplet.

Kazdopadne diky za predzvykani.

[Trained.Monkey]

Pred par dny tady byla zpravicka o opraveni IO scheduleru. Na nekterem hardware linux prakticky zamraza pri kopirovani. Nemate nekdo zpravy jestli tahle oprava bude v novem jadru?

[Bedňa]

Tak máš ten hardvér rozbitý. Kopírovanie nerobí žiadne problémy. V scheduleri opravovali chyby pri extrémnom zaťažení IO.

[Trained.Monkey]

Ve Windows, Solaris ani FreeBSD to nedela. Takze pro linux je asi extremni zatizeni 20MB/s

[Bedňa]

Pre každého je "extrém" niečo iné No dobre je možné že to poslednými úpravami naozaj rozbili, pretože som narazil na informácie že sa to bude riešiť.

[BrainLess]

Ja mam zkusenost s timto. 2jadrove cpu asi 4gb ram. Dve LOOP zarizeni kryptovana pres AES. Pri kopirovani z jednoho na druhe. Normalni cp /mnt/prvni_loop_zarizeni na /mnt/druhe_loop_zarizeni to zcela bezpecne zabije kernel ve smyslu (ne nevytuhne to) jenom se rychlost kopirovani snizi na hranici KB/sec pritom to zacne klasicky na cca 40-50MB/sec. Imho je tam neco hodne hloupe resene a zacne to swapovat a utlouka se to na tom swapovani.

[Tom K]

Podle toho. co bylo v 2.6.36-rc2, tak to tam bude (v diffech se to da najit).

[Nikola Ciprich]

dnes vysla zpravicka o patchich pro -stable rady oprava je tam obsazena...

[Petr Ježek]

Btrfs je vzhledem k současnému stavu vývoje, testování a nasazení ideální pro odzkoušení alokací podle teploty. Kdyby se to pustilo na vyšší úrovni, znamenalo by to znásobení práce počtem FS, v nichž by se funkcionalita testovala bey yáruky uspokojivého výsledku. Pokud to bude na základě koncentrovaného testování a ladění v btrfs bezproblémové a dle představ, není žádný problém posunu výše s následným rychlým zapracováním. Efektivnost vývoje musí být, pocity a dojmy jsou dobré jako sociální výplň...