Jaderné noviny – 10. 11. 2011: Kvóty u tmpfs

21. 11. 2011 | Luboš Doležel

Články - Jaderné noviny – 10. 11. 2011: Kvóty u tmpfs  

Aktuální verze jádra: 3.2-rc1. Citáty týdne: Dan Magenheimer, Ingo Molnar. Kvóty u tmpfs. Začleňovací okno 3.2, druhá polovina. Lepší správa výkonu ve verzi 3.2.

Obsah

• Aktuální verze jádra: 3.2-rc1
• Citáty týdne: Dan Magenheimer, Ingo Molnar
• Kvóty u tmpfs
• Začleňovací okno 3.2, druhá polovina
• Lepší správa výkonu ve verzi 3.2

Aktuální verze jádra: 3.2-rc1

Aktuální vývojová verze jádra je 3.2-rc1 vydaná 7. listopadu. Užijte si to, dopřejte tomu náležitého testování. Nemělo by tam být nic extra děsivého, ale *je* toho tam hodně. Fakt, že se verze 3.1 protáhla, zapříčinil, že je toto jedním z větších začleňovacích oken, ale nejsem kvůli tomu až *tak* nervózní. Má to nové kódové jméno – Šavlozubá veverka.

Stabilní aktualizace: verze 2.6.32.47 a 2.6.33.20 vyšly 7. listopadu; obě obsahují dlouhý seznam důležitých oprav. 2.6.32.48 vyšlo 8. listopadu s opravou problému se sestavením, které se objevily v 2.6.32.47. Uživatelé řady 2.6.33 by měli vzít na vědomí, že 2.6.33.20 je poslední plánovanou aktualizací.

Citáty týdne: Dan Magenheimer, Ingo Molnar

Testovací figurína se prohýbá.
KVM mafie vítězí.
Inovace spláče.

-- Dan Magenheimer

Beze srandy, kdyby mi někdo dal nástroj v tools/term/, který má základní funkčnost xtermu s podporou tabů, napsaný nad čistým libdri a převzal by celou obrazovku, přešel bych na to během 0,5 nanosekundy a dělal bych v tom většinu mého každodenního kódování a vypomohl bych s rozšířením o další aplikace (pravděpodobně počínaje rozumným mailovým klientem).

-- Ingo Molnar

Kvóty u tmpfs

Druhá verze údržbářského [plumber's] seznamu přání pro Linux obsahuje žádost o podporu kvót u souborového systému tmpfs. Aktuální jádra takovou podporu nemají, což usnadňuje místním uživatelům udělat DoS útok zaplněním /tmp nebo /dev/shm. Davidlohr Bueso vyslyšel tuto žádost patchem, který tuto podporu doplňuje. Ale ukázalo se, že zde panuje neshoda ohledně toho, jak by limity tmpfs měly být spravovány.

Davidlohrův patch ve skutečnosti neimplementuje kvóty; namísto toho přidává nové omezení prostředků (RLIMIT_TMPFSQUOTA), který řídí, kolik místa může uživatel využít na všech připojených tmpfs. Tento přístup je v seznamu přání vyžadován; něco na něm je, neboť tmpfs není perzistentní souborový systém. Běžné implementace souborových systémů ukládají kvóty v souborovém systému samotném, ale tmpfs to udělat nemůže. Takže použití kvót by znamenalo, že by uživatelský prostor musel nějakým způsobem opětovně načítat databázi kvót při každém bootu (nebo, v závislosti na implementaci, při každém připojení tmpfs). Omezení prostředků vypadají jako jednodušší situace.

I tak má přístup přes omezení prostředků své odpůrce. Vývojáři by raději viděli, kdyby se tmpfs chovalo stejně jako ostatní souborové systémy. Navíc uživatelé a aplikace snad mají trochu ponětí o tom, jak reagovat na chyby o „překročení kvóty“. Překročené limity prostředků nemají tak pevnou pozici. Jak Alan Cox podotkl, načítání kvót nemusí být takový problém; mohlo by jít třeba jen o něco tak jednoduchého jako volba pro mount, která určí výchozí kvótu pro všechny uživatele.

Nakonec to nevypadá, že by implementace založená na něčem jiném než diskových kvótách, byla začleněna, takže tento patch bude muset být přepracován.

Začleňovací okno 3.2, druhá polovina

Dne 7. listopadu oznámil Linus vydání verze 3.2-rc1 a uzavřel začleňovací okno. Během čtrnáctidenního okna bylo do hlavní řady přetaženo nějakých 10 214 neslučovacích změn. To z něj dělá nejaktivnější začleňovací okno v historii, docela slušně překonávajíc předchozího držitele rekordu (2.6.30, 9603 změn). Zpoždění na začátku tohoto vývojového cyklu bezpochyby způsobilo nahromadění práce, ale tak či tak se toho obecně více dělo.

Změny viditelné pro uživatele od shrnutí z minulého týdne zahrnují:

• Device mapper (mapovač zařízení) má novou schopnost „tenkého provisioningu“, který mimo jiné nabízí vylepšenou podporu pro snapshoty. Tato funkce je ve verzi 3.2 považována za experimentální. Vizte Documentation/device-mapper/thin-provisioning.txt pro informace o tom, jak to funguje. Do device mapperu přibyl i modul „bufio“, který mezi systém a blokové zařízení přidává další vrstvu bufferování; kód tenkého provisioningu je hlavním uživatelem této funkce.
• Přibylo nové zařízení virtio mapované do paměti, které umožní virtualizovaným hostům používat bloková a síťová zařízení na bázi virtio bez podpory PCI.
• Nyní je možné používat poll() na souborech v /proc/sys; výsledkem je to, že dostanete upozornění, jakmile se určitý parametr sysctl změní.
• Souborový systém btrfs nyní zaznamenává počet předchozích kořenů stromu, což se může hodit při obnově poškozeného souborového systému; vizte tento článek pro více informací. Btrfs také získalo lepší podporu readahead (přednačítání).
• Byl zařazen patch pro brzdění zápisu špinavých stránek [I/O-less dirty throttling]; měl by zlepšit výkon zpětného zápisu v řadě situací.
• Přehled nových ovladačů najdete v originále článku.

Změny viditelné vývojářům jádra zahrnují:

• Nový příznak zařízení GENHD_FL_NO_PART_SCAN, který potlačí běžné načítání oddílů při přidávání zařízení do systému.
• Ctihodná funkce blokové vrstvy __make_request() byla přejmenována na blk_queue_bio() a vyexportována modulům.
• Příznak nečistoty [taint flag] TAINT_OOT_MODULE je nyní nastaven, jakmile je vložen modul nepocházející ze stromu. Samozřejmě toto o sobě řekne jádru sám modul, takže tento mechanismus je možné obejít, ale kdokoliv, kdo se o to pokusí, bude dříve či později přistižen a veřejně zostuděn.
• Několik maker (EXPORT_SYMBOL_* a THIS_MODULE) bylo odloučeno z <linux/module.h> a umístěno do <linux/export.h>. Kód, který jen potřebuje exportovat symboly, může nyní používat druhý jmenovaný soubor; výsledkem je zkrácení času pro kompilaci.

Navzdory velikosti tohoto vývojového cyklu nebyla přetažena řada stromů. Linus se otevřeně vyhnul všem kontroverzním (např.: FrontSwap a nástroj KVM); jiné byly jednoduše přeskočeny. Některé mohou proklouznout do -rc2, ale teď hlavně přišel čas na stabilizování tohoto kódu. Pokud bude platit pravidlo, tak můžeme vydání 3.2 čekat někdy kolem poloviny ledna.

Lepší správa výkonu ve verzi 3.2

Linuxové jádro už má dlouho schopnost regulovat napětí a frekvenci CPU pro optimální chování, kde „optimální“ je funkcí zohledňující výkon i spotřebu energie. Ale v systému je toho více než jen CPU a je tam řada dalších komponent, které mohou běžet na vícero úrovních výkonu. Není překvapením, že náležitá infrastruktura pro správu řídících bodů zařízení je pozadu oproti té pro CPU, neboť množství uspořené energie je typicky menší. Ale teď, když už je chování výkonu CPU poměrně dobře optimalizované, infrastruktura pro výkon se rozrůstá tak, aby mohla zahrnout zbytek systému. Jádro 3.2 bude mít novou sadu API zamýšlenou pro ovladače, aby systém mohl najít nejlepší úroveň fungování pro zařízení, která spravuje.

API pro dynamické škálování napětí a frekvence (dynamic voltage and frequency scaling; DVFS) má tři oddělené kousky, první z nichž byl začleněn už v 2.6.37. Modul „míst pracovního výkonu“ [operating power points] jednoduše sleduje různé úrovně práce dostupné u daného zařízení; API je deklarováno v <linux/opp.h>. Ve stručnosti se místa úrovně práce se spravují pomocí:

int opp_add(struct device *dev, unsigned long freq, unsigned long u_volt);
int opp_enable(struct device *dev, unsigned long freq);
int opp_disable(struct device *dev, unsigned long freq);

Úrovně práce jsou ve výchozím stavu povoleny; ovladač může zakázat určité úrovně v závislosti na obavě o teplotu nebo výkon. Existuje sada funkcí pro získávání úrovní práce nad nebo pod danou frekvencí, což je užitečné pro posun nahoru nebo dolu po měřítku výkonnosti.

Ovladač, který chce podporovat DVFS na určitém zařízení, začne vyplněním jedné takové struktury (která je deklarovaná spolu se zbytkem API v <linux/devfreq.h>):

struct devfreq_dev_profile {
	unsigned long initial_freq;
	unsigned int polling_ms;

	int (*target)(struct device *dev, unsigned long *freq);
	int (*get_dev_status)(struct device *dev,
			      struct devfreq_dev_status *stat);
	void (*exit)(struct device *dev);
};

Nepřekvapí, že initial_freq je původní pracovní frekvencí zařízení. Téměř všechno ostatní v této struktuře slouží ku pomoci správcům frekvence [frequency governors] při odvádění práce. Pokud je polling_ms nenulové, dává to správci vědět, jak často se má dotazovat zařízení ohledně aktuálního vytížení; toto dotazování bude mít podobu volání get_dev_status(). Tato funkce by měla naplnit strukturu stat relevantními informacemi:

struct devfreq_dev_status {
	/* both since the last measure */
	unsigned long total_time;
	unsigned long busy_time;
	unsigned long current_frequency;
	void *private_data;
};

Správce použije tuto informaci k rozhodnutí, zda by aktuální pracovní frekvence měla být změněna, nebo ne. Pokud je nutná změna, zpětné volání target() bude zavoláno pro příslušnou změnu pracovní úrovně. Tato funkce by měla vybrat frekvenci alespoň tak vysokou, jako je předána v *freq, a následně aktualizovat *freq dle aktuálně vybrané frekvence. Zpětné volání exit() dává ovladači možnost věci vyčistit, pokud se vrstva DVFS rozhodne na zařízení zapomenout.

Jakmile je struktura devfreq_dev_profile vyplněna, ovladač udělá registraci pomocí:

struct devfreq *devfreq_add_device(struct device *dev,
				       struct devfreq_dev_profile *profile,
				       const struct devfreq_governor *governor,
				       void *data);

Pokud je to potřeba, ovladač může dodat svého vlastního správce pro řízení frekvencí, ale jádro má několik vlastních: devfreq_powersave (udržuje frekvenci na nejnižší možné úrovni), devfreq_performance (udržuje frekvenci co nejvýše), devfreq_userspace (umožní řízení frekvencí přes sysfs) a devfreq_simple_ondemand (snaží se udělat kompromis mezi výkonem a spotřebou energie).

Notifikační mechanismus vestavěný do kódu úrovně práce může být použit k automatickému vyvolání správce, pokud by se sada dostupných úrovní práce změnila. Existuje řada způsobů, jakými by k takové změně mohlo dojít; jednou z jich je změna v očekáváních, jak rychle dokáže zařízení odpovídat. V tomto případě získalo jádro 3.2 také vylepšení v kódu quality of service (pm_qos), aby docházelo k ošetření QOS požadavků jednotlivých zařízení. Jaderný kód může vyjádřit QOS očekávání u zařízení za pomoci jedné z těchto funkcí (všechny jsou z <linux/pm_qos.h>):

int dev_pm_qos_add_request(struct device *dev, struct dev_pm_qos_request *req,
			       s32 value);
int dev_pm_qos_update_request(struct dev_pm_qos_request *req, s32 new_value);
int dev_pm_qos_remove_request(struct dev_pm_qos_request *req);

Struktura dev_pm_qos_request je používána jako deskriptor pro správu požadavků, ale volající kód nemusí přistupovat k jejímu obsahu. Předaná hodnota value popisuje zamýšlenou kvalitu služby; dokumentace je překvapivě vágní v tom, jaká je jednotka této hodnoty. Zdá se, že popisuje požadovanou latenci, ale kýžená přesnost je nejistá.

Na straně ovladače se používá rozhraní notifikátoru:

int dev_pm_qos_add_notifier(struct device *dev,
			    	struct notifier_block *notifier);
int dev_pm_qos_remove_notifier(struct device *dev,
			           struct notifier_block *notifier);

Jakmile se změní požadavky na kvalitu služby u tohoto zařízení, notifikátor bude zavolán s novou hodnotou. Ovladač pak může upravit dostupné úrovně práce, například zakázáním těch, při kterých by pak zařízení nebylo schopno splnit požadovanou kvalitu služeb.

Nutno poznamenat, že tento nový kód nemá doposud ve stromu žádné uživatele. To může znamenat, že toto rozhraní může být poněkud méně stálé; jakmile začnou vývojáři tyto funkce užívat, pravděpodobně najdou věci, které by šlo zlepšit. Jenže interní rozhraní jsou tak jako tak vždy možným předmětem změn; možnému rozvoji navzdory, tato schopnost by měla být užitečná.

Diskuse k tomuto článku

[Jendа]

Tabbingem se podle mě myslí panely/karty/záložky/ouška.

Seriously, if someone gave me a tools/term/ tool that has rudimentary xterm functionality with tabbing support, written in pure libdri and starting off a basic fbcon console and taking over the full screen,

Beze srandy, kdyby mi někdo dal nástroj v tools/term/, který má základní funkčnost xtermu bez podpory tabulátoru, napsaný nad čistým libdri a převzal by celou obrazovku

[Luboš Doležel (Doli)]

To mě nenapadlo. A evidentně mě to zblblo natolik, že jsem tam ještě mimoděk dal zápor. Díky.

[Zopper]

Nevím, jestli je pojem "záložka" nejlepší verzí - dokud jsem nepřečetl komentář s originálem, přemýšlel jsem, jak to s těma záložkama (chápáno jako bookmarks) může být myšleno. Osobě bych tam raději viděl "s podporou karet/tabů" - tady by snad nemělo dojít k záměně za jiný termín.

[Petr Ježek]

Reagujete na tu největší zbytečnost, která se v jaderné vývojové větvi řeší. TMPFS nic?

[Jindřich Makovička]

TMPFS nic. Ale jestli půjde v Linuxu konečně kopírovat na USB flashku a přitom normálně pracovat, bude to taková malá revoluce :)

[Jiří J.]

Jó, to už částečně funguje. S 3.2 to bude ještě lepší (tedy pokud IO-less dirty throttling bude podobný tomu, který jsem zkoušel ve formě patchů z linux-fsdevel).

[Jindřich Makovička]

Zkusil jsem 3.2-rc3 a desktop se při rsyncu většího množství dat z SSD na HDD chová výrazně lépe.

[mimi.vx]

vam to nejde?

[pavlix]

Ale jestli půjde v Linuxu konečně kopírovat na USB flashku a přitom normálně pracovat, bude to taková malá revoluce :)

Ono to někdy nešlo?

[Jindřich Makovička]

Pokud jde o mojí zkušenost, v době, kdy se objevily defaultně zapnuté Transparent Huge Pages, to kvůli pár regresím nešlo vůbec, systém prostě přestal reagovat do té doby, než se dokopírovalo. Teď se při kopírování akorát dostupná RAM zaplácne dirty pages čekajícími na zápis a systém se občas na 15-20 sekund odmlčí.

Podobně se to chová při kopírování SSD->HDD, což mě během zálohování pouštěného z cronu taky celkem otravuje. Asi budu muset 3.2-rc vyzkoušet.

[pavlix]

Takovou zkušenost jsem nezískal.