abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 14:55 | Zajímavý článek

Nová čísla časopisů od nakladatelství Raspberry Pi: MagPi 81 (pdf), HackSpace 18 (pdf), Hello World 8 (pdf) a Wireframe 11 (pdf) a 12 (pdf).

Ladislav Hagara | Komentářů: 0
dnes 01:22 | Nová verze

Po více než 4 měsících vývoje od vydání verze 15 byla vydána nová stabilní verze 16 open source systému Nextcloud (Wikipedie), forku ownCloudu, umožňujícího provoz vlastního cloudového úložiště. Přehled novinek i s náhledy v příspěvku na blogu. Pro vyzkoušení Nextcloudu je k dispozici demo (aktuálně verze 15).

Ladislav Hagara | Komentářů: 0
dnes 01:00 | Nová verze

Node.js Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 12.0.0 (Current) otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). Přehled novinek v článku na Medium. Verze 12 se v říjnu stane novou aktivní LTS verzí. Podpora je plánována do dubna 2022.

Ladislav Hagara | Komentářů: 1
dnes 00:44 | Nová verze

Byla vydána verze 11.10 open source alternativy GitHubu, tj. softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech, GitLab (Wikipedie). Představení nových vlastností i s náhledy v příspěvku na blogu.

Ladislav Hagara | Komentářů: 0
dnes 00:11 | IT novinky

OpenAI, nezisková organizace pro výzkum umělé inteligence (AI), představila projekt MuseNet. Jedná se o hlubokou neuronovou síť, která dokáže generovat čtyřminutové hudební skladby s 10 různými nástroji a kombinovat styly od country přes Mozarta až po Beatles.

Ladislav Hagara | Komentářů: 5
včera 16:00 | Pozvánky

Spolek OpenAlt zve příznivce otevřených řešení a přístupu na 163. brněnský sraz, který proběhne v pátek 26. dubna od 18:00 v indické restauraci Everest na adrese Veveří 61.

Ladislav Hagara | Komentářů: 5
včera 15:33 | IT novinky

Všem dívkám v ICT vše nejlepší k dnešnímu Mezinárodnímu dni dívek v ICT (Wikipedie, Girls in ICT Day, YouTube).

Ladislav Hagara | Komentářů: 8
včera 12:22 | Nová verze

Byla vydána verze 1.12 systému pro správu a verzování zdrojových kódů Apache Subversion (Wikipedie). Přehled novinek v poznámkách k vydání.

Ladislav Hagara | Komentářů: 11
včera 12:11 | Zajímavý článek

Mozilla zveřejnila každoroční Internet Health Report, který popisuje aktuální společenská témata související s využíváním Internetu. Tentokrát se dotýkají mj. etiky algoritmů strojového učení, cílené reklamy a „chytrých měst“.

Fluttershy, yay! | Komentářů: 2
včera 08:44 | Nová verze

Webová aplikace pro správu repozitářů v gitu Gitea vyšla v nové verzi 1.8.0. Nově poskytuje OAuth 2.0, umožňuje archivaci repozitářů, skrývání organizací jako interních či soukromých, zamykání konverzací a mnoho dílčích změn.

Fluttershy, yay! | Komentářů: 6
Používáte headset pro virtuální realitu?
 (1%)
 (3%)
 (2%)
 (18%)
 (1%)
 (75%)
Celkem 241 hlasů
 Komentářů: 12, poslední 18.4. 01:19
Rozcestník

Jaderné noviny – 27. 5. 2009

23. 6. 2009 | Jirka Bourek | Jaderné noviny | 3524×

Aktuální verze jádra: 2.6.30-rc7. Citáty týdne: Al Viro, Andi Kleen, Andrew Morton. V krátkosti: Sjednocené adresáře; Optimalizace časovačů zpětného zápisu; recvmmsg(). Vývojové statistiky 2.6.30. Compcache: Komprimované swapování do paměti. Aktualizovaná příručka debugfs.

Obsah

Aktuální verze jádra: 2.6.30-rc7

link

Současné vývojové jádro je 2.6.30-rc7 vydané 23. května. Tak se odvažte. Mám podezření, že udělám -rc8, ale rozhodně se blížíme k vydání – bylo by dobré to otestovat, jak nejvíc to půjde, a mělo by být poměrně bezpečné to všechno vyzkoušet. Detaily obsahuje kompletní changelog.

Současné stabilní jádro 2.6 je stále 2.6.29.4; během minulého týdne nebyly vydány žádné stabilní verze.

Citáty týdne: Al Viro, Andi Kleen, Andrew Morton

link

Je zajímavé, že říct někomu, že se musí naučit C, se považuje za neakceptovatelné. Nepřátelské k nováčkům nebo tak něco. Na druhou stranu zavádět další kouzla, která je potřeba se naučit, aby si někdo mohl přečíst zdrojové kódy jádra, je naprosto v pořádku...

-- Al Viro

Sorry, ale opravdu tvrdíš, že by každý program na světě, který někde používá write(), měl toto volání vložit do smyčky? To mi připadá jako opravdu špatný návrh API, když je zapotřebí u tak zásadního systémového volání takových obezliček, aby se obešly nedostatky jádra.

Dokážu si představit, jak programátoři před takové smyčky vkládají komentáře se sprostými výrazy na adresu jádra, přičemž tyto komentáře by byly plně zasloužené.

-- Andi Kleen objevil POSIX

Hej, na mě nekoukej – za to může Brian Kernighan nebo George Bush nebo někdo.

-- Andrew Morton se zříká zodpovědnosti

V krátkosti

link

Sjednocené adresáře

link

Zatímco mnoho vývojářů pracuje na problému kompletního sjednoceného připojení, Miklos Szeredi používá jednodušší přístup: sjednocené adresáře. Ty poskytují sjednocení pouze na úrovni nejvyššího adresáře a měnit lze pouze souborový systém na nejvyšší úrovni. To odstraňuje potřebu napsat spoustu komplexního kódu, který by zajišťoval kopírování adresářů výše, vybělení a podobných, ale také významně omezuje funkce.

Optimalizace časovačů zpětného zápisu

link

Na normálním linuxovém systému se proces pdflush probouzí každých pět vteřin, aby vynutil zápis špinavých stránek na úložiště. K tomuto probuzení dochází bez ohledu na to, jestli je něco potřeba zapsat. Zbytečná probouzení jsou čím dál tím méně vítaná, obzvláště na systémech, kde záleží na spotřebě energie, takže by bylo hezké nechat pdflush spát, když není co na práci.

Artem Bityutskiy sestavil sadu patchů, která to zajistí. Mění API souborových systémů, aby se jádru VFS zjednodušilo zjišťování, jestli má daný souborový systém špinavá data. Tato informace se poté použije k rozhodnutí o tom, jestli je potřeba budit pdflush ze spánku. Tento nápad vypadá dobře, ale je zde jeden malý problém: Tato práce je v konfliktu s patchi zapisovacích vláken pro jednotlivé BDI, které připravuje Jens Axboe. Jensovy patche se zbavují časovače pdflush a dělají spoustu dalších změn, takže tyto dva projekty se v současnosti příliš nesnesou. Artem se tedy vrací k rýsovacímu prknu, aby svou práci založil na Jensových patchích místo na hlavní řadě.

recvmmsg()

link

Arnaldo Carvalho de Melo navrhl nové systémové volání pro API socketů:

struct mmsghdr {
    struct msghdr   msg_hdr;
    unsigned        msg_len;
};

ssize_t recvmmsg(int socket, struct mmsghdr *mmsg, int vlen, int flags);

Rozdíl mezi tímto systémovým voláním a recvmsg() spočívá v tom, že může přijmout několik zpráv v jednom volání. To omezuje režii systémových volání u síťových aplikací s velkou propustností. Komentáře v patchi naznačují, že sendmmsg() se plánuje, ale ještě nebyla zaslána žádná implementace.

Padl návrh, že tuto funkci by bylo možné získat rozšířením recvmsg() novým příznakem zprávy místo přidáváním nového systémového volání. Jak ale upozornil David Miller, to nebude fungovat. Jádro v současnosti ignoruje příznaky, které nepoznává; z toho důvodu by uživatelský prostor neměl možnost rozpoznat, jestli specifické jádro podporuje přijímání několika zpráv naráz, nebo ne. Tato funkčnost tedy bude pravděpodobně přidána v novém systémovém volání.

Vývojové statistiky 2.6.30

link

Jak se vývojový cyklus 2.6.30 blíží ke svému konci, je přirozené ohlédnout se za tím, co bylo začleněno a odkud to přišlo. Zde je tedy tradiční pohled Jaderných novin na to, kdo napsal kód, který se tentokrát dostal do hlavní řady.

2.6.30 byl opět rozsáhlý vývojový cyklus; zahrnoval začlenění (i když těsně po 2.6.30-rc7) 11 733 neslučovacích sad změn od 1125 vývojářů. Počet sad změn překračuje 2.6.29, ale počet vývojářů se snížil z 1166, které jsme viděli minule. Tito vývojáři tentokrát přidali 1,14 milionů řádků kódu, přičemž odstranili 513 000, takže čistý přírůstek je 624 000 řádků.

Statistiky jednotlivých vývojářů vypadají takto:

Nejaktivnější vývojáři 2.6.30
Podle sad změn
Ingo Molnár3242,8 %
Bill Pemberton2271,9 %
Stephen Hemminger2041,7 %
Hans Verkuil1991,7 %
Takashi Iwai1881,6 %
Bartlomiej Zolnierkiewicz1861,6 %
Steven Rostedt1791,5 %
Greg Kroah-Hartman1501,3 %
Jeremy Fitzhardinge1251,1 %
Mark Brown1070,9 %
Jaswinder Singh Rajput1050,9 %
Rusty Russell1000,9 %
Tejun Heo980,8 %
Johannes Berg980,8 %
Hannes Eder880,8 %
Michal Šimek850,7 %
Luis R. Rodriguez850,7 %
Sujith850,7 %
David Howells800,7 %
Yinghai Lu780,7 %
Podle změněných řádků
Greg Kroah-Hartman1203539,0 %
ADDI-DATA GmbH434203,3 %
Mithlesh Thukral424243,2 %
Alex Deucher265762,0 %
David Schleef259051,9 %
David Woodhouse246361,8 %
Ramkrishna Vepa234951,8 %
Lior Dotan225061,7 %
Eric Moore222661,7 %
Eilon Greenstein183991,4 %
Jaswinder Singh Rajput181681,4 %
Hans Verkuil180481,4 %
David Howells179411,3 %
Andy Grover163551,2 %
Michal Šimek158271,2 %
Sri Deevi155141,2 %
Frank Mori Hess154501,2 %
Ben Hutchings150311,1 %
Ingo Molnár138761,0 %
Bill Pemberton138171,0 %

Co se sad změn týče, na špičce seznamu je tentokrát Ingo Molnár; jako vždy vytvořil ohromné množství patchů – přibližně pět za den – pro kód architektury x86, ftrace a dalších. Bill Pemberton je možná známější jako správce poštovního klienta Elm; udělal spoustu pročišťovací práce na ovladačích COMEDI ve stromě -staging. Jádro práce Stephena Hemmingera spočívá v konverzi síťových ovladačů na nové API net_device_ops. Hans Verkuil pokračuje v práci na zlepšování frameworku Video4Linux2 a s ním spojených ovladačů a Takashi Iwai vytváří spousty patchů jako správce ALSA.

Linus odpálil vývojový cyklus 2.6.30 s poznámkou, že přibližně třetina změn v 2.6.30-rc1 je „svinstvo“. Není tedy překvapení, že první tři místa ve sloupečku „podle změněných řádek“ dosáhla svého umístění přispíváním do -staging ovladačů. Alex Deucher přidal podporu pro Radeon R6xx/R7xx; mnoho z jeho „změněných řádek“ je firmware mikrokódu těchto karet. A David Schleef přidal do stromu -staging další sadu ovladačů.

Příspěvky do 2.6.30 lze vysledovat k nějakým 190 zaměstnavatelům. Při pohledu na informace o nejaktivnějších zaměstnavatelích vidíme:

Nejaktivnější zaměstnavatelé v 2.6.30
Podle sad změn
(žádný)197016,8 %
Red Hat130511,1 %
(neznámý)118410,1 %
Intel8557,3 %
Novell8327,1 %
IBM6305,4 %
(konzultant)2932,5 %
Atheros Communications2622,2 %
Oracle2522,1 %
University of Virginia2271,9 %
Fujitsu2171,8 %
Vyatta2041,7 %
Renesas Technology1521,3 %
NTT1211,0 %
MontaVista1151,0 %
HP1070,9 %
Wolfson Microelectronics1050,9 %
(školství)1020,9 %
Nokia980,8 %
XenSource910,8 %
Podle změněných řádek
(neznámý)18141313,6 %
Novell16422912,3 %
(žádný)1180958,9 %
Intel860606,5 %
Red Hat739545,5 %
LinSysSoft Technologies647984,9 %
ADDI-DATA GmbH434203,3 %
SofaWare392452,9 %
Broadcom319562,4 %
AMD283642,1 %
Entropy Wave259051,9 %
IBM257021,9 %
Oracle255881,9 %
NTT252351,9 %
Neterion234951,8 %
LSI Logic223041,7 %
Atheros Communications216271,6 %
(konzultant)192091,4 %
Freescale161391,2 %
PetaLogix158461,2 %

Čísla jsou v podstatě podobná těm, která jsme viděli v předchozích vývojových cyklech. Objevuje se zde několik méně známých firem; většinou jsou přítomny díky příspěvkům do stromu -staging. Stojí za to poznamenat, že Broadcom a Atheros, dříve známé jako nespolupracující společnosti, postupem času své příspěvky rozšiřují.

Autor článku Jonathan Corbet se během posledních několika cyklů nedíval na statistiky podpisů. Na značkách Podepsáno-kým [Signed-off-by] je zajímavé to, že z nich lze usoudit, kdo jsou vrátní jádra. Obzvláště když se zanedbají podpisy autorů každého patche, zůstatkem jsou (většinou) podpisy správců subsystémů, kteří schválili začlenění patche. Pro 2.6.30 čísla vypadají takto:

Nejvíce neautorských podpisů v 2.6.30
Jednotlivci
David S. Miller121612,1 %
John W. Linville8658,6 %
Ingo Molnár8368,3 %
Greg Kroah-Hartman7977,9 %
Mauro Carvalho Chehab7847,8 %
Andrew Morton6606,6 %
James Bottomley2502,5 %
Linus Torvalds2192,2 %
Len Brown1891,9 %
Takashi Iwai1651,6 %
Jeff Kirsher1451,4 %
Russell King1271,3 %
H. Peter Anvin1201,2 %
Mark Brown1151,1 %
Jesse Barnes1111,1 %
Benjamin Herrenschmidt1111,1 %
Reinette Chatre1041,0 %
Martin Schwidefsky950,9 %
Avi Kivity910,9 %
Paul Mundt890,9 %
Zaměstnavatelé
Red Hat426442,4 %
Novell138613,8 %
Intel9519,5 %
Google6606,6 %
(žádný)4084,1 %
IBM3783,8 %
Linux Foundation2192,2 %
(konzultant)1661,6 %
(neznámý)1271,3 %
Wolfson Microelectronics1151,1 %
Renesas Technology920,9 %
Marvell910,9 %
Atomide810,8 %
Oracle800,8 %
Astaro650,6 %
Freescale630,6 %
Cisco610,6 %
Analog Devices600,6 %
Univ. of Michigan CITI590,6 %
Panasas580,6 %

Podpisy jsou vždy rozděleny mezi menší počet vývojářů než příspěvky. I tak se ale jeden podivuje nad tím, jak David Miller zvládá schválit nějakých 20 patchů každý den. Na straně zaměstnavatelů jsou záležitosti koncentrovanější než kdy jindy; více než polovina patchů, které míří do jádra, prochází pod rukama někoho z Red Hatu nebo Novellu. Vývojáři, zdá se, pracují pro velký počet společností, ale správci subsystémů mají tendence soustřeďovat se jenom v hrstce z nich.

Ve shrnutí stále vidíme dobře promazaný, rychle se pohybující vývojový proces. Také vidíme obraz stromu -staging, který roste závratnou rychlostí; Jonathan je v pokušení patche -staging z budoucích hlášení vyjmout, pokud se toto tempo trochu nesníží. I bez stromu -staging se nicméně na jádře hodně pracuje, na čemž se účastní velká skupina vývojářů; a nezdá se, že by se to mělo v blízké budoucnosti měnit.

Dodatek: Jan Engelhardt zaslal Jonathanovi odkaz na krátký skript, který použitím příkazu git blame určuje vlastnictví každého řádku v jádře. První příčky v 2.6.30-rc7 vypadají takto:

Kdo se poslední dotkl řádek kódu
Řádek%Kdo
406372335,17 % Linus Torvalds
4640214,02 % Greg Kroah-Hartman
942000,82 % David Howells
860310,74 % David S. Miller
826080,71 % Luis R. Rodriguez
722000,62 % Bryan Wu
701280,61 % Takashi Iwai
668590,58 % Ralf Baechle
557850,48 % Hans Verkuil
540690,47 % Paul Mundt
540070,47 % Kumar Gala
532880,46 % David Brownell
516400,45 % Russell King
506110,44 % Paul Mackerras
494990,43 % Andrew Victor
493470,43 % Mauro Carvalho Chehab
492560,43 % Alan Cox
473050,41 % Mikael Starvik
470400,41 % Ben Dooks
443070,38 % Benjamin Herrenschmidt

Linus vlastní velký počet řádek, protože v počátku éry gitu do něj vkládal kód. Podle přibližného odhadu se dá usoudit, že na jednu třetinu kódu se od té doby nesáhlo. Se statistikami na úrovni jednotlivých řádků se dají udělat další zajímavé věci; autor článku má v úmyslu tuto možnost někdy v budoucnu prozkoumat.

Compcache: Komprimované swapování do paměti

link

Originál tohoto článku pro LWN.net napsal Nitin Gupta

Myšlenka komprese paměti – komprimace relativně nepoužívaných stránek a jejich ukládání v samotné paměti – je jednoduchá a existuje již dlouho. Komprese je díky eliminaci drahého I/O na disk mnohem rychlejší než swapování těchto stránek na sekundární úložiště. Když je stránka opět zapotřebí, je dekomprimována a vrácena, což je – opět – mnohem rychlejší než jít pro ni do swapu.

Implementace této myšlenky v Linuxu je v současnosti ve vývoji jako projekt compcache. Vytváří virtuální blokové zařízení (nazvané ramzswap), které se chová jako swapovací disk. Stránky odswapované na tento disk jsou zkomprimovány a uloženy do paměti. Domovská stránka projektu obsahuje informace o možných použitích, číslech o výkonnosti a další údaje. Zaměření projektu není jenom výkonnost – na systémech bez swapu umožňuje běh aplikací, které by jinak jednoduše selhaly kvůli nedostatku paměti. Například Edubuntu zahrnulo compcache, aby se snížila náročnost jeho instalátoru na RAM.

Stránka o výkonnosti na wiki projektu ukazuje čísla pro konfigurace, které se blíží netbookům, tenkým klientům a embedded zařízením. Tyto počáteční výsledky vypadají slibně, například v benchmarku pro tenké klienty ramzswap poskytuje téměř stejný efekt jako zdvojnásobení paměti. Další benchmark ukazuje, že průměrný čas potřebný k dokončení požadavků na čtení nebo zápis do swapu je s ramzswap drasticky snížen. Se swap oddílem umístěným na disku s 10000 rpm se průměrný čas požadavku na čtení a zápis do swapu pohyboval okolo 168 ms a 355 ms v uvedeném pořadí. S ramzswap byly tyto hodnoty 12 µs a 7 µs – v tom je započtena i doba testu, jestli stránka obsahuje samé nuly, a komprese/dekomprese nenulových stránek.

Přístup používající virtuální blokové zařízení představuje oproti předchozím pokusům významné zjednodušení. Předchozí implementace vyžadovaly změny v cestě zápisu do swapu, obsluhy výpadku stránky a funkcích pro vyhledávání v cachích stránek (find_get_page() a spol.). Tyto patche nebyly všeobecně přijaty kvůli své rušivé povaze. Nový přístup je mnohem méně rušivý, ale za určitou cenu: Compcache ztratila schopnost komprimovat stránky z cache stránek (obsahující data ze souborového systému). Nyní je možné komprimovat jen stránky swapu (anonymní). Zároveň ale tato jednoduchost a nerušivost zajistila začlenění projektu do Ubuntu, ALT Linux, LTSP (Linux Terminal Server Project) a možná do dalších.

Mělo by být poznamenáno, že když je použit na úrovni hypervizoru, compcache dokáže komprimovat jakoukoliv část paměti hosta bez ohledu na to, o jakého hosta (Linux, Windows atd.) jde – to by mělo umožnit spouštět více virtuálních strojů pro dané množství celkové paměti hostitele. Například fyzická paměť hosta je u KVM pro hostitele (v tomto případě linuxové jádro) jednoduše anonymní paměť. S nedávnou podporou MMU notifikátoru začleněného do linuxového jádra je nyní téměř celá fyzická paměť hosta odswapovatelná [PDF].

Implementace

link

Všechny jednotlivé komponenty jsou oddělené jaderné moduly:

  • LZO kompresor: lzo_compress.ko, lzo_decompress.ko (již v hlavní řadě)
  • paměťový alokátor xvMalloc: xvmalloc.ko
  • ovladač blokového zařízení compcache: ramzswap.ko

Jakmile jsou tyto moduly nahrány, stačí pouze aktivovat swapovací zařízení ramzswap:

swapon /dev/ramzswap0

Všimněte si, že ramzswap není možné použít jako obecné blokové zařízení, zvládá pouze I/O zarovnané na jednotlivé stránky, což dostačuje pro použití jako swapovací zařízení. Zatím se neobjevil žádný případ, který by ospravedlnil snahu vytvořit obecné komprimující blokové zařízení pro čtení i zápis. Aby se minimalizovala režie blokové vrstvy, používá ramzswap režim práce „bez fronty“. Tím přijímá požadavky přímo z blokové vrstvy a vyhýbá se tak veškeré režii spojené s frontou požadavků.

Modul přijímá parametry určující velikost „disku“, omezení paměti a záložní swapovací oddíl. Volitelný záložní swapovací oddíl je oddíl, kam ramzswap přepošle požadavky na zápis/čtení stránek, které se zkomprimují na velikost větší než PAGE_SIZE/2 – v paměti se tak udržují jenom dobře komprimovatelné stránky. Navíc se stránky testují a pokud je nějaká zaplněná pouze nulami, nealokuje se pro ni žádná paměť. Pro „obvyklou“ zátěž desktopu (Firefox, poštovní klient, editor, přehrávač atd.) vidíme typicky 4000–5000 stránek zaplněných nulami.

Správa paměti

link

Jedna z největších výzev tohoto projektu bylo spravovat komprimované kousky paměti o různých velikostech. K tomu ramzswap používá paměťový alokátor xvMalloc vyvinutý specificky pro tento projekt. Má O(1) malloc/free, velmi malou fragmentaci (do 10 % od ideální hodnoty ve všech testech) a umí využívat horní paměť (užitečné na systémech s více než 1 G paměti). Exportuje nestandardní rozhraní alokátoru:

struct xv_pool *xv_create_pool(void);
void xv_destroy_pool(struct xv_pool *pool);

int xv_malloc(struct xv_pool *pool, u32 size, u32 *pagenum, u32 *offset, gfp_t flags);
void xv_free(struct xv_pool *pool, u32 pagenum, u32 offset);

xv_malloc() vrací pár <pagenum, offset>. Tuto stránku poté musí namapovat volající (pomocí kmap()) a tím získat platný ukazatel v jaderném prostoru.

Ospravedlnění pro využívání vlastního alokátoru paměti bylo poskytnuto, když byly do linux-kernel zaslány patche compcache. Alokátory SLOB i SLUB se ukázaly být pro tento projekt nepoužitelné. SLOB se zaměřuje na embedded zařízení a tvrdí, že má velkou prostorovou efektivitu. Ukázalo se nicméně, že má nějaké významné problémy: Chování alloc/free je O(n) a může vést k velkému množství vyplýtvaného prostoru, což je detailněji rozebráno v tomto příspěvku v LKML.

Na druhou stranu SLUB má jinou sadu problémů. První je neobvyklá záležitost s fragmentací: Data prezentovaná zde ukazují, že kmalloc používá přibližně o 43 % více paměti než xvmaloc. Další problém je, že aby omezil fragmentaci, závisí na alokací stránek vyšších řádů. To pro ramzswap není akceptovatelné, protože se používá v situacích, kdy je paměti málo, takže alokace vyšších řádů téměř jistě selžou. Alokátor xvmalloc na druhou stranu, když potřebuje rozšířit svůj fond paměti, alokuje stránky nultého řádu.

Navíc jak SLUB, tak SLOB jsou omezeny na alokace z dolní paměti. Toto omezení konkrétně platí pouze pro 32bitové systémy s více než 1 G paměti. Na takových systémech ani jeden z alokátorů není schopen alokovat z oblasti horní paměti. Toto omezení není pro projekt compcache akceptovatelné, uživatelé s takovými konfiguracemi hlásili selhání při alokaci paměti pro ramzswap (před tím, než byl vyvinut xvmalloc), i když byla k dispozici spousta horní paměti. Alokátor xvmalloc je schopen alokovat z oblasti horní paměti.

Vzhledem k výše uvedeným bodům by xvmalloc mohl potenciálně nahradit SLOB alokátor. To by nicméně zahrnovalo spoustu další práce, protože xvmalloc poskytuje nestandardní rozhraní malloc/free. Ve svém současném stavu navíc xmvalloc není škálovatelné (to není ani SLOB), takže nemůže být zvažováno jako náhrada za SLUB.

Paměť potřebná pro alokaci komprimovaných stránek není předalokována; zvětšuje se a zmenšuje podle potřeby. Při inicializaci ramzswap vytváří fond paměti xvmalloc. Když fond nemá dostatek paměti k uspokojení požadavku na alokaci, zvětší se alokací jediné stránky (nultý řád) od jaderného alokátoru stránek. Když je objekt uvolněn, xvmalloc sloučí s ním sousedící volné bloky ve stejné stránce. Jestliže je výsledná velikost volného bloku rovna PAGE_SIZE, tj. když stránka neobsahuje žádný objekt, je uvolněna zpátky jádru.

Tato alokace a uvolňování objektů může vést k fragmentaci paměti ramzswap. Uvažme případ, kde je v krátkém čase uvolněno mnoho objektů a následně je velmi málo požadavků na zápis do swapu. V takovém případě může xvmalloc skončit s mnoha částečně zaplněnými stránkami, z nichž každá bude obsahovat pouze malé množství živých objektů. Aby byl tento případ řešen, bude potřeba implementovat nějaký druh defragmentace paměti xvmalloc; to by bylo možné provést přemístěním objektů z téměř prázdných stránek do jiných stránek ve fondu xvmalloc. Je však třeba podotknout, že po měsících praktického používání na desktopových strojích plýtvání pamětí kvůli fragmentaci nikdy nepřekročilo 7 %.

Omezení swapu a nástroje

link

Vzhledem k tomu, že jde o blokové zařízení, nemůže ramzswap vědět, že je komprimovaná stránka zastaralá – řekněme, že proces, který ji vlastní, se ukončil. Takové (komprimované) stránky jednoduše plýtvají pamětí. S nedávnou podporou zahození swapu [swap discard] to ale není tak velkým problém. Zahození swapu vysílá bio požadavek BIO_RW_DISCARD, když najde volný cluster swapu během alokace. I když compcache neobdrží zpětné volání [callback] ihned poté, co stránka zastará, je to stále lepší, než když jsou takové stránky udržovány v paměti, dokud nejsou přepsány jinou stránkou. Podpora pro mechanismus zahození swapu byla přidána do compcache-0.5.

Obecně požadavek na zahození přichází dlouho poté, co stránka zastarala. Vezměme případ, když se proces intenzivně využívající paměť ukončí a nedochází k žádnému dalšímu swapování. V takových případech v ramzswapu zůstane spousta zastaralých stránek. Vzhledem k tomu, že nedochází k dalším požadavkům na swapování, ramzswapu nepřijdou žádné požadavky na zahození swapu; lze očekávat, že pro některé z těchto zastaralých stránek přijdou požadavky k zahození, až když se znovu začne swapovat.

Aby se se tedy ramzswap zefektivnil, jsou potřeba změny v jádře (ještě neprovedeny), aby byla bitová mapa swapu prohledávána agresivněji a tak nalézány uvolněné clustery swapu – přinejmenším v případě, že je RAM zálohována swapovacím zařízením. Adaptivní politika změn velikosti komprimované cache by také byla užitečná – mohla by monitorovat přístupy ke komprimované cache a málo používané stránky přesunout na fyzické swapovací zařízení. V současnosti může ramzswap přeposlat nekomprimovatelné stránky zpět na záložní disk, ale nemůže odswapovat paměť alokovanou xvmalloc.

Další zajímavý podprojekt je infrastruktura SwapReplay. Tento nástroj je určen ke snadnějšímu testování chování paměťového alokátoru za podmínek skutečného swapování. Je to jaderný modul a sada nástrojů v uživatelském prostoru, které umí přehrát swapovací události. Jaderný modul fyzické swapovací zařízení překrývá pseudoblokovým zařízením (/dev/sr_relay). Když jádro přes toto pseudoswapovací zařízení swapuje, pošle do uživatelského prostoru kombinaci <číslo sektoru, R/W bit, zkomprimovanou délku> a pak I/O požadavek přepošle skutečnému swapovacímu zařízení (určeného parametrem swap_replay modulu). Získaná data lze potom procházet k tomu určenou knihovnou, která poskytuje rozhraní pro zpětné volání pro události swapu. Klienty používající tuto knihovnu mohou pro tyto události poskytnout jakoukoliv akci – zobrazit histogramy zkomprimované délky, simulovat chování ramzswap atd. Pro tuto funkci není nutné žádné patchování jádra.

Infrastruktura přehrávání swapu byla pro vývoj ramzswap velmi užitečná. Možnost přehrát využívání swapu umožňuje jednoduché a konzistentní simulace pro jakoukoliv zátěž bez potřeby ji nastavit a spouštět znovu a znovu. Jestliže uživatel trpí s některými druhy zátěže velkou fragmentací, může Nitinovi zaslat výpis swapování pro tuto zátěž a on tím bude mít všechna data potřebná k reprodukování stavu u sebe – bez nutnosti připravit stejnou zátěž.

Byly napsány klienty pro procházející knihovnu, které simulují chování ramzswap podle výpisů různých druhů zátěže, aby se zjednodušilo hodnocení různých alokátorů paměti a tím nakonec i vývoj a zlepšování alokátoru xvmalloc. V budoucnosti to také pomůže testování různých politik vytěsňování [eviction] při podpoře adaptivních změn velikosti cache.

Závěr

link

Projekt compcache je v současnosti aktivně vyvíjen; některé z dalších plánovaných vlastností jsou: Adaptivní změna velikosti komprimované cache, možnost swapování paměti xvmalloc na fyzický swapovací disk, defragmentace paměti přesunutím komprimovaných kousků v paměti a komprimované swapování na disk (4–5 stránek odswapováno během jediného I/O na disk). Později by mohlo dojít k rozšíření pro komprimování cachí stránek (což dělaly starší patche) – v současnosti obsahuje pouze komponentu ramzswap, která řeší kompresi anonymní paměti.

Když byly naposledy patche ramzswap zaslány k revizi, byla jako odůvodnění této vlastnosti poskytnuta jenom výkonnostní data LTSP. Andrewu Mortonovi tato data nestačila. Nyní je na wiki stránce projektu o výkonnosti nahráno mnohem více dat, která ukazují zlepšení výkonnosti, které ramzswap poskytuje. Andrew také poukázal na nedostatek informací o případech, když ramzswap působí zhoršení výkonnosti:

Také bychom rádi viděli zhoršení výkonnosti kvůli těmto patchům. Někde musí být režie. Najděte nejhorší testovací případ a spusťte ho a jeho výsledky do changelogu vložte také, abychom lépe porozuměli, co tady měníme za co.

Projekt pro tyto případy data stále postrádá. Měla by nicméně být k dispozici někdy v době 2.6.32, kdy budou tyto patche znovu zaslány pro možné začlenění do hlavní řady.

Aktualizovaná příručka debugfs

link

Na LWN se API debugfs zabývali roku 2004. V poněkud méně dávné době Shen Feng nabídl, že by článek o debugfs začlenil jako soubor v adresáři Documentation. V tomto návrhu spočíval jenom jeden malý problém: Jak by se dalo očekávat, API debugfs se od roku 2004 trochu změnilo. Následující text je pokus aktualizovat původní dokument, aby pokrýval celé API tak, jak existuje v jádře 2.6.30.

Debugfs existuje jako jednoduchý způsob, jakým mohou vývojáři jádra zpřístupnit informace uživatelskému prostoru. Na rozdíl od /proc, které má obsahovat pouze informace o procesech, či sysfs, které má striktní pravidlo „v jednom souboru jedna hodnota“, nemá debugfs pravidla žádná. Vývojáři tam mohou vložit, jaké informace chtějí. Souborový systém debugfs navíc nemá sloužit jako stabilní ABI do uživatelského prostoru; teoreticky se na soubory sem exportované nevztahují žádná omezení na stabilitu. Skutečnost nicméně není vždy tak jednoduchá; i rozhraní debugfs je nejlépe navrhovat s myšlenkou na to, že je bude potřeba spravovat navždy.

Debugfs se typicky připojuje příkazem, jako je tento:

mount -t debugfs none /sys/kernel/debug

(nebo odpovídající řádkou v /etc/fstab.) V mailových konferencích občas vzniká neshoda o tom, kde je správné místo pro připojování debugfs, a některá dokumentace se odkazuje na jiné připojovací body jako /debug. V současnosti je kód v uživatelském prostoru, který používá soubory v debugfs, přenositelnější, pokud si přípojný bod najde v /proc/mounts.

Všimněte si, že API debugfs je modulům exportováno jako pouze-GPL.

Kód používající debugfs by měl vkládat <linux/debugfs.h>. První věc, kterou je pak nutno udělat, je vytvoření alespoň jednoho adresáře, který bude obsahovat sadu souborů debugfs:

struct dentry *debugfs_create_dir(const char *name, struct dentry *parent);

Toto volání, pokud uspěje, vytvoří adresář pojmenovaný name v určeném adresáři parent. Pokud je parent NULL, adresář bude vytvořen v kořeni debugfs. Při úspěchu je návratová hodnota ukazatel na struct dentry, který lze použít k vytváření souborů v daném adresáři (a k jeho vyčištění na konci). Návratová hodnota NULL indikuje, že se něco nepovedlo. Pokud je vráceno -ENODEV, znamená to, že jádro bylo přeloženo bez podpory debugfs a že žádná z funkcí popsaných níže nebude fungovat.

Nejobecnější způsob, jak v adresáři debugfs vytvořit soubor, je:

struct dentry *debugfs_create_file(const char *name, mode_t mode,
                                   struct dentry *parent, void *data,
                                   const struct file_operations *fops);

Zde je name jméno souboru, který má být vytvořen, mode popisuje oprávnění, která má soubor mít, parent udává, ve kterém adresáři má být soubor uložen, data se uloží do pole i_private výsledné struktury inodefops je sada operací se souborem, která implementuje chování souboru. Minimálně by měly být poskytnuty operace read() a/nebo write(); další mohou být přidány podle potřeby. Návratová hodnota je opět ukazatel na dentry výsledného souboru, NULL, pokud došlo k chybě, nebo -ENODEV, pokud chybí podpora debugfs.

V mnoha případech není vytvoření sady operací se souborem zapotřebí; kód debugfs pro jednoduché situace poskytuje mnoho pomocných funkcí. Soubor obsahující jedinou celočíselnou hodnotu lze vytvořit kteroukoliv z následujících:

struct dentry *debugfs_create_u8(const char *name, mode_t mode,
                                 struct dentry *parent, u8 *value);
struct dentry *debugfs_create_u16(const char *name, mode_t mode,
                                  struct dentry *parent, u16 *value);
struct dentry *debugfs_create_u32(const char *name, mode_t mode,
                                  struct dentry *parent, u32 *value);
struct dentry *debugfs_create_u64(const char *name, mode_t mode,
                                  struct dentry *parent, u64 *value);

Tyto soubory podporují jak čtení, tak zápis předané hodnoty; pokud do specifického souboru nemá být možné zapisovat, stačí jednoduše nastavit odpovídající bity v mode. Hodnoty v těchto souborech jsou vypsány desítkově; pokud je vhodnější šestnáctkový zápis, lze použít tyto funkce:

struct dentry *debugfs_create_x8(const char *name, mode_t mode,
                                 struct dentry *parent, u8 *value);
struct dentry *debugfs_create_x16(const char *name, mode_t mode,
                                  struct dentry *parent, u16 *value);
struct dentry *debugfs_create_x32(const char *name, mode_t mode,
                                  struct dentry *parent, u32 *value);

Všimněte si, že není debugfs_create_x64().

Tyto funkce jsou užitečné, pokud vývojář zná velikost hodnoty, která se exportuje. Některé typy však mohou mít na různých architekturách různé velikosti, což situaci poněkud komplikuje. Existuje funkce, která pomůže v jednom zvláštním případě:

struct dentry *debugfs_create_size_t(const char *name, mode_t mode,
                                     struct dentry *parent, 
                                     size_t *value);

Jak lze odhadnout, tato funkce vytvoří v debugfs soubor, který reprezentuje proměnnou o velikosti size_t.

Pravdivostní hodnoty lze do debugfs vložit voláním:

struct dentry *debugfs_create_bool(const char *name, mode_t mode,
                                   struct dentry *parent, u32 *value);

Čtení výsledného souboru vrací buď Y (pro nenulové hodnoty) nebo N následované znakem pro nový řádek. Zapisovat je možné malá i velká písmena a hodnoty 10.

Jakákoliv jiná vstupní hodnota je v tichosti ignorována.

A nakonec je takto možné exportovat libovolná binární data:

struct debugfs_blob_wrapper {
    void *data;
    unsigned long size;
};

struct dentry *debugfs_create_blob(const char *name, mode_t mode,
                                    struct dentry *parent,
                                    struct debugfs_blob_wrapper *blob);

Čtení z tohoto souboru vrátí data, na která ukazuje struktura debugfs_blob_wrapper. Některé ovladače „bloby“ používají jako jednoduchý způsob, jak vrátit několik řádek (statického) formátovaného textového výstupu. Tuto funkci lze použít k exportu binárních informací, ale nezdá se, že by to v hlavní řadě nějaký kód dělal. Všimněte si, že soubory vytvořené pomocí debugfs_create_blob() jsou pouze pro čtení.

K dispozici je několik pomocných funkcí zaměřených na adresáře:

struct dentry *debugfs_rename(struct dentry *old_dir, 
    				  struct dentry *old_dentry,
		                  struct dentry *new_dir, 
				  const char *new_name);

struct dentry *debugfs_create_symlink(const char *name, 
                                          struct dentry *parent,
				      	  const char *target);

Volání debugfs_rename() dá existujícímu souboru v debugfs nové jméno, které může být i v jiném adresáři; new_name nesmí před voláním existovat, návratová hodnota je old_dentry s aktualizovanou informací. Symbolické odkazy lze vytvořit pomocí debugfs_create_symlink().

Je zde jedna důležitá věc, se kterou musí všichni uživatelé debugfs počítat: Žádné adresáře vytvořené v debugfs nejsou automaticky pročišťovány. Jestliže je modul odstraněn, aniž by explicitně záznamy v debugfs smazal, výsledkem bude spousta neplatných ukazatelů a velká spousta velmi nespolečenského chování. Všichni uživatelé debugfs – nebo alespoň ti, které lze přeložit jako moduly – musí být připraveni odstranit všechny soubory a adresáře, které vytvoří. Soubor lze odstranit voláním:

void debugfs_remove(struct dentry *dentry);

Hodnota dentry může být NULL.

Bylo nebylo, uživatelé debugfs si museli pamatovat ukazatele na dentry pro všechny soubory, které vytvořili, aby je později mohli pročistit. Nyní nicméně žijeme v civilizovanějších časech, takže stačí zavolat:

void debugfs_remove_recursive(struct dentry *dentry);

Když je této funkci předán ukazatel na dentry odpovídající nejvyššímu adresáři, je celá hierarchie v tomto adresáři smazána.

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

Karry avatar 23.6.2009 16:24 Karry | skóre: 10
Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 5. 2009
Hans Verkuil pokračuje v práci na zlepšování frameworku Video4Linux2...

Nesledujete to někdo? Čeho se zlepšování týká? V posledních měsících jsem vůbec nestíhal sledovat, o prázdninách bych se ale rád zas zapojil do vývoje...
unzip; strip; touch; grep; finger; mount; fsck; more; yes; umount; sleep
Karry avatar 23.6.2009 16:32 Karry | skóre: 10
Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 5. 2009
...unálený dotaz, stačilo použít google... na lwn je to shrnuté: http://lwn.net/Articles/203924/
unzip; strip; touch; grep; finger; mount; fsck; more; yes; umount; sleep
Voty avatar 23.6.2009 18:31 Voty | skóre: 12 | blog: gemini
Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 5. 2009

Tak o té compcache jsem dosud neměl tušení a vypadá to docela zajímavě. Podařilo se mi do 4 GiB paměti nacpat 5,1 GiB a ještě je cca 100 MiB volných. Vskutku zajímavé.

Jednu rozbil a tu druhou ztratil.
23.6.2009 19:19 Kvakor
Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 5. 2009
Pamatuju, že QEMM 9(?) pro Windows 3.x dělal něco podobného - uzmul část paměti, kterou komprimoval, a teprve po jejím vyčerpání použival normální swap. Ve Windows 3.x, které použivaly na I/O volání DOSu, takže jakékoliv snížení přístupů k disku mělo smysl.
Karry avatar 23.6.2009 19:28 Karry | skóre: 10
Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 5. 2009
I dnes to má smysl. V booku mám disk 5400ot s přístupovou dobou větší než malou, když systém začne swapovat tak si můžu jít postavit vodu na kafe...
unzip; strip; touch; grep; finger; mount; fsck; more; yes; umount; sleep
23.6.2009 19:55 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 5. 2009
Já jsem zkoušel udělat program, který v cyklu alokuje, zapíše a leakuje paměť. Bez compcache ho OOM killer odstřelil po 1GB alokované paměti, s compcache (500MB "swap") po 1.5GB
Quando omni flunkus moritati
Karry avatar 23.6.2009 20:00 Karry | skóre: 10
Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 5. 2009
A zkoušel jsi při tom zapisování celou alokovanou paměť "vynulovat" ? Tak by se podle mě dalo dosáhnout do maxima virtuálního prostoru, pokud je to implementováno tak jak myslím. :)
unzip; strip; touch; grep; finger; mount; fsck; more; yes; umount; sleep
24.6.2009 12:12 trekker.dk | skóre: 71
Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 5. 2009
Zkoušel. Problém je v tom, že když spustím takovýhle program, tak se samozřejmě nejdřív odswapuje paměť ostatních programů, která se ovšem nekomprimuje tak dobře jako samé nuly.

S 1GB swapem se povedlo alokovat 1.5GB paměti (po OOM bylo 1300MB volné). S 1.5GB swapem to bylo 2GB.
Quando omni flunkus moritati
Bilbo avatar 23.6.2009 22:06 Bilbo | skóre: 29
Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 5. 2009
Jo, s programy ktere kvuli nejake chybe (nebo kvuli pusteni na vstupu, jehoz "velikost presahuje vsechny meze") zacnou alokovat pamet "rychle do nekonecna" plati "cim vice swapu, tim dele trva nez zasahne OOM a tim vice mezitim harddisk chrasti". Nastesti to jde resit ulimitem (dobra hodnota je soft ulimit na polovinu fyzIcke pameti), ktery si pro opravdu narocne programy explicitne zvednu
Big brother is not watching you anymore. Big Brother is telling you how to live...
23.6.2009 22:11 M. Lox | skóre: 12
Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 5. 2009
Já už to používám dost dlouho, dozvěděl jsem se o tom odtud. Na 128 MiB paměti je to k nezaplacení.
make menuconfig, not war!
Nicky726 avatar 24.6.2009 00:43 Nicky726 | skóre: 56 | blog: Nicky726
Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 5. 2009
Jo vypadá to fakt dobře. Na starších strojích s méně ram by to mohlo být velmi užitečné.
Enjoy the detours. There you’ll find the things more important than what you want. (Hunter x Hunter)
26.6.2009 15:48 valesek
Rozbalit Rozbalit vše Re: Jaderné noviny – 27. 5. 2009
Dik za tu komprimaci swap v ram, zkusim jeste dnes to jadro na svym notesu, kterej se neda pametove rozsirit ze 128MB. Valesek

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.