Portál AbcLinuxu, 8. května 2025 04:40
Aktuální verze jádra: 3.7-rc6. Citáty týdne: Tejun Heo, Peter Stuge, Steven Rostedt, Avi Kivity. Reportáž z multimediálního sumitu v Barceloně. Sledování často používaných dat ve VFS.
Aktuální vývojová verze jádra je 3.7-rc6 vydaná 16. listopadu; od odjezdu Linuse na dovolenou se věci moc nehýbaly. Mám s sebou na cestách notebook, ale kdyby se věci uklidnily, měl bych radost. Vydám -rc7, ale vzhledem k dosavadnímu poklidnému vývoji si myslím, že to bude poslední -rc. Leda by se událo něco dramatického.
Stabilní aktualizace: verze 3.0.52, 3.2.34, 3.4.19 a 3.6.7. Všechny vyšly 17. listopadu s obvyklými opravami.
Někdy je děsivé, kolik skrytých bugů v jádře máme a jak dlouho tam některé z nich byly. Jindy vás to zase uklidňuje. Tím mám na mysli, že je docela slušná šance, že si ostatní nevšimnou mých průšvihů, no ne?
-- Tejun Heo
Konečný výsledek: Daný ovladač zařízení na daném systému s Windows zhavaruje právě jednou.
-- Peter Stuge na téma proč se Linux možná bude muset chovat stejně
Přečetl jsem si ten řádek několikrát a stále mi to zní jako nějaký pokřik řeckých stávkařů...
"Zkonsolidujte to trochu! Kód pro přepínání kontextu!"
"Zkonsolidujte to trochu! Kód pro přepínání kontextu!"
"Zkonsolidujte to trochu! Kód pro přepínání kontextu!"
"Zkonsolidujte to trochu! Kód pro přepínání kontextu!"
Asi je to tím, že mi to zní jako řečtina.
Po šesti a půl letech psaní a spravování KVM je čas, abych se posunul k jiným věcem.
-- Avi Kivity předává práci Glebu Natapovi
Hans Verkuil zaslal reportáž ze setkání jaderných vývojářů z oblasti multimédií z nedávného sumitu v Barceloně. Mezi témata patří nová organizace podsprávců, požadavky na nové ovladače V4L2, asynchronní načítání a další. Počet zasílaných patchů se zvýšil z 200 za měsíc před dvěma lety na letošních 700 za měsíc. Mauro ten nával nezvládá a je třeba najít řešení.
Na všech úrovních systému, od hardwaru až po vysokoúrovňové aplikace, výkon často závisí na uchovávání často používaných dat tam, kam se k nim dá dostat rychle. Toto je principem za hardwarovou cachí, virtuální pamětí a cachí obrázků ve webových prohlížečích, mimo jiné. Jádro se už snaží ponechávat užitečná data ze souborového systému v cachi stránek pro rychlý přístup, výhodné ale může být i sledování často používaných dat na úrovni souborového systému a speciální zacházení s takovými daty. V roce 2010 byl zaslán patch pro sledování „teploty dat“ pro Btrfs, pak ale zájem odezněl. Nyní se tento nápad vrátil v obecnější podobě. Aktuální podoba patche od Zhia Yonga Wua se nazývá sledování žhavých dat (hot-data tracking). Pracuje na úrovni virtuálního souborového systému (VFS), sleduje přístupy k datům a zpřístupňuje výsledné údaje uživatelskému prostoru pomocí různých mechanismů.
Prvním krokem je sledování VFS za účelem získání potřebných informací. Zhiův patch přidává háčky do řady hlavních funkcí VFS (__blockdev_direct_IO(), readpage(), read_pages() a do_writepages()), aby zaznamenával určité operace. Stojí za to upozornit, že háčky na této úrovni znamenají, že subsystém nesleduje přístup k datům jako takový; místo toho sleduje operace způsobující skutečné I/O. To nejsou ty samé věci: často čtená stránka, která zůstává v cachi, nebude způsobovat žádné I/O; pro tento patch by taková data vypadala jako nezajímavá („studená“).
Patch používá tyto háčky pro generování překvapivě složité struktury dat zahrnující několik RB stromů, které jsou napojeny do struktury superblock daného systému souborů. Zhi Yong k popisu v dokumentaci, jenž je součástí patche, použil tento úchvatný ASCII art:
heat_inode_map hot_inode_tree
| |
| V
| +-------hot_comm_item--------+
| | frequency data |
+---+ | list_head |
| V ^ | V
| ...<--hot_comm_item-->... | | ...<--hot_comm_item-->...
| frequency data | | frequency data
+-------->list_head----------+ +--------->list_head--->.....
hot_range_tree hot_range_tree
|
heat_range_map V
| +-------hot_comm_item--------+
| | frequency data |
+---+ | list_head |
| V ^ | V
| ...<--hot_comm_item-->... | | ...<--hot_comm_item-->...
| frequency data | | frequency data
+-------->list_head----------+ +--------->list_head--->.....
Ve zkratce je myšlenkou sledovat, kterým inodům se dostává největšího provozu spolu s nejzajímavějšími rozsahy dat v rámci těchto inodů. Subsystém dokáže sestavit seřazený seznam na žádost. Ani nepřekvapí, že na vytíženém systému tato struktura dokáže používat hodně paměti, proto Zhi Yong přidal funkčnost, která data vyčistí, jakmile je málo místa. Konkrétní informace o souboru jsou navíc zahozeny po pěti minutách (ve výchozím nastavení), kdy se souboru nedostává aktivity.
Přibylo nové volání ioctl() (FS_IOC_GET_HEAT_INFO), pomocí něhož se dá získat relevantní informace o konkrétním souboru. Struktura, kterou používá, dodává informace, jež jsou k dispozici:
struct hot_heat_info {
__u64 avg_delta_reads;
__u64 avg_delta_writes;
__u64 last_read_time;
__u64 last_write_time;
__u32 num_reads;
__u32 num_writes;
__u32 temp;
__u8 live;
};
Subsystém sledování žhavých dat sleduje počty operací čtení a zápisu, kdy k poslední operaci došlo a průměrnou prodlevu mezi operacemi. Komplikovaný výpočet tyto informace zkombinuje do jediné hodnoty udávající teplotu, ta je uložena v temp. Pole live je vstupním parametrem pro volání ioctl(); je-li nenulové, teplota bude přepočítána v době volání; jinak bude vrácena cachovaná starší hodnota.
Volání ioctl() neposkytuje žádný způsob pro dotazování na to, které části souboru jsou nejžhavější nebo které soubory obecně jsou nejžhavější. Místo toho se musí použít rozhraní debugfs. Jakmile je debugfs připojeno, každé zařízení nebo oddíl s připojeným systémem souborů bude vyjádřen adresářem pod hot_track/ obsahujícím dva soubory. Nejaktivnější soubory lze odhalit přečtením rt_stats_inode, zatímco nejžhavější části souborů lze číst z rt_stats_range. Toto jsou rozhraní, která mají být používána nástroji v uživatelském prostoru při rozhodování, například o tom, které soubory (nebo části souborů) by měly být uloženy na rychlém SSD.
Pokud by systém souborů chtěl ovlivnit to, jak je výpočet prováděn, patch poskytuje strukturu (zvanou hot_func_ops) jako místo pro funkce poskytnuté systémem souborů pro výpočet frekvence přístupů, teploty a určení, kdy mají staré informace být odstraněny. V zaslaném patchi používá funkci sledování často používáných souborů jen Btrfs a to této možnosti nevyužívá, proto není úplně jasné, k čemu je. Seznam změn zmiňuje, že byla implementována podpora pro ext4 a xfs; snad to bude právě jeden z této dvojice systémů souborů, který to na něco potřebuje.
Patch prošel několika cykly revidování a na základě připomínek se dočkal spousty změn. Zbývá ještě udělat testování škálovatelnosti, jednodušší funkci pro výpočet teploty a schopnost ukládat informace o teplotě souborů pro zachování při odpojení systému souborů. Před začleněním do VFS bude ještě nutné dodat nějaké náležitě připravené informace o výkonu. Proto tato funkce ještě nemíří do řady 3.8, ale dočkat bychom se ji mohli v jednom z dalších cyklů.
.
Díky moc za článek.
10.12.2012 21:59
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
13.12.2012 23:29
Luboš Doležel (Doli) | skóre: 98
| blog: Doliho blog
| Kladensko
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.