OS X Mavericks a komprese paměti

Jestli ještě nemáte poslední OS X 10.9 Mavericks, pak přicházíte o skvělou novinku, kterou je komprese paměti. Inženýři z Cupertina o této funkci mluví spíše marketingově, takže většinou ukazují nic neříkající srovnání a grafy.

Co to ale vlastně znamená a jaký je přínos? Jak to funguje? Je to vůbec k něčemu? Nebude vlastní proces komprese a dekomprese pomalejší, než když se paměť jednoduše odswapuje na disk?

Autorem článku je Kuba Břečka. @kubabrecka bloguje na svém blogu iOSák o iOS, Xcode, Objective-C, Cocoa Touch, mobilním vývoji, Applu a bezpečnosti. To vše je proloženo fotkami koťátek.

Podívejme se na to, jak vypadá vytížení paměti na mém obstarožním MacBooku se 4 GB RAM. Nejprve ve stavu, kdy nemám spuštěný prakticky žádný program, a pak ve stavu, kdy spustím hromadu paměťově náročných aplikací.

Už tady je vidět spousta zajímavých údajů: Memory Used mi hlásí, že je zaplněno 3,99 GB ze 4 GB prakticky pořád, tj. systém nemá naprosto žádnou volnou paměť, i když nemám nic spuštěno. Pokud vás tento fakt šokuje nebo si říkáte “ten OS X jsou ale hloupý systém”, pak je mi líto, ale dál nečtěte, nepochopili jste základní principy správy paměti v moderním OS.

Ale nejste v tom sami, ani na Windows, ani na Mac OS X, ani na Linuxu. Numerologové na to mají různé rady, co s tím. Osobně jsem viděl i experty, kteří se podívají ve Windows do Task Manageru, uvidí v kolonce “Free memory” nulu a řeknou “nojo, musíš si koupit víc RAMky”.

Pojďme dále, můj systém v klidovém stavu vůbec nepoužívá swap. Tak by to mělo být. Ale že systém nepoužívá vůbec žádný swap, i když mám spuštěno 20 paměťově náročných aplikací? Tak to vypadá opravdu slušně! Tohle je oproti předchozím OS X velký rozdíl, minimálně na mém stroji by starý OS X v této situaci používal alespoň gigo nebo dvě swapu.

Černá magie?

V době klidu ukazovala hodnota App Memory hodnotu 1,68 GB, což bych tak nějak očekával – na pozadí běží řada procesů, kernel a drivery taky něco sežerou. Když jsem ale spustil těch 20 aplikací, App Memory ukazuje 2,13 GB – to je nějak podezřele málo! Hergot, vždyť jenom ten Photoshop sám si určitě ukrojí půl giga. Odpověď je ale samozřejmě nasnadě: Většina paměti náročných aplikací je zkomprimována a tedy se nachází v kolonce Compressed. Dohromady (půl giga navíc v App Memory a 600 MB v Compressed) to dává, že můj systém na těchto 20 aplikací potřeboval jenom něco málo přes 1 GB paměti! Což ukazuje na účinnost komprese, protože bez ní by aplikace zabraly určitě přes 3 GB.

Nabízí se otázka, kde systém vzal ten gigabajt paměti, když už předtím žádnou volnou paměť neměl. Odpovědí je File Cache, tj. paměť, která slouží především pro optimalizaci čtení z disku. Data, která byla v poslední době přečtena z disku, se při příštím přístupu nebudou načítat znovu, ale jsou nakešována. Pokud systém potřebuje další paměť, stačí některá data z keše vyhodit. Pokud jste někdy použili příkaz purge, pak vězte, že ten nedělá nic jiného, než že odstraní všechna data z této keše. Modří již vědí, že spouštět tento příkaz je zbytečné ba dokonce kontraproduktivní – výkon systému to jenom zhorší.

Nejvíc nejasností panuje o tzv. Wired Memory (zadrátovaná), tedy paměti, která nemůže být odswapována ani zkomprimována. Dokumentace poměrně přesně popisuje, jaká paměť je zadrátovaná, a kde se bere: Jedná se o struktury kernelu, ke kterým je potřeba přistupovat, aniž by mohlo dojít k výpadku stránky. Takže třeba stránkovací tabulky, údaje o procesech a vláknech, kód a data ovladačů a kernelových rozšíření. Už je ale problém zjistit, co přesně zabírá kolik místa v paměti, protože systém tyto údaje prostě neposkytuje. Respektive umí je zpřístupnit debug verze kernelu, takže jestli se vám chce si překompilovat kernel s flagem MACH_VM_DEBUG, získáte možnost přes syscall mach_vm_region_info zjistit, která přesně paměť je zadrátovaná.

Ale zpět ke kompresi – co to vlastně je za černou magii, která umí ze tří gigabajtů udělat jeden? Která umí udržet v paměti 20 náročných aplikací, aniž by cokoliv odswapovala na disk? A když je to tak šikovné, proč moderní OS nemají kompresi paměti jako běžnou funkci?

Zázračná komprese

Apple vydává řadu svého softwaru jako open-source a již dokonce zveřejnil zdrojáky od svého kernelu xnu ve verzi 2422.1.72, který je právě použit v OS X Mavericks. Kód zodpovědný za kompresi a dekompresi lze najít v souborech WKdmCompress_new.s a WKdmDecompress_new.s a jedná se o upravenou implementaci algoritmu WKdm, pojmenovaný podle tvůrců Paula Wilsona a Scotta Kaplana (“dm” znamená direct-mapped, protože algoritmus používá přímo mapovaný slovník).

Ačkoliv běžné kompresní algoritmy jsou optimalizované na co největší úsporu místa, WKdm má za prioritu co nejrychlejší (de)kompresi. To je pochopitelné, protože pokud by byl algoritmus pomalý, nic bychom oproti swapování nezískali, a ještě by to spotřebovalo více energie. Přesto je ale WKdm v kompresi velice úspěšný! Využívá totiž toho, že se velice často v paměti opakují některé vzory, nebo že stránky v paměti často obsahují samé nuly. Autoři analyzovali právě takového vzory a výsledkem je algoritmus, který je až překvapivě jednoduchý:

• Algoritmus čte po slovech (32 bitů, a to i na 64bitových strojích) a snaží se komprimovat vždy jednu stránku (4 kB)
• Má slovník o 16 slovech
• Každé slovo ze stránky je potom zařazeno do jedné ze čtyř kategorií:
  1. je nulové – je zkomprimováno do dvou bitů 00 (ze 32 bitů zbydou 2)
  2. celé slovo je ve slovníku – je zkomprimováno do bitů 11 následováno čtyřbitovým indexem do slovníku (úspora 26 bitů)
  3. vrchních 22 bitů slova je shodných se slovem ve slovníku – je zkomprimováno do bitů 01 následováno čtyřbitovým indexem do slovníku a zbylými deseti bity (úspora 16 bitů)
  4. ani jedno z předchozích – na výstup jdou bity 10 a celé aktuální slovo (o 2 bity větší než původně)

Takový je princip, implementace je samozřejmě o něco složitější (zejména vytváření slovníku), navíc ji Apple ručně zoptimalizoval v assembleru. Výše zmíněné zdrojáky však mají v úvodu hezky popsaný celý algoritmus. Je zřejmé, že dekomprese je triviální úkol.

Asi není třeba rozebírat, že na jiné úlohy by tento algoritmus byl naprosto nevhodný. Co myslíte, jak by si poradil s běžným textovým dokumentem?

Cílem není zrychlení

No a proč takhle paměť nekomprimují ostatní OS? Především celá myšlenka komprese je pořád dost kontroverzní – není vůbec zřejmé, že zrovna vašemu systému přinese nějaké zrychlení, klidně se může stát, že bude na škodu. Dalším problémem je volba algoritmu a vhodného kompromisu mezi zátěží CPU a kvalitou komprese. Kromě toho, implementace takovéto fičury do jádra obnáší enormní úsilí – přecijenom správa paměti a swapování je něco, co se obvykle moc nemění. V neposlední řadě něco takového mohlo přijít až v době, když máme všichni dostatečně výkonná CPU, aby nebyla znát lehce zvýšená zátěž procesoru.

Článek původně vyšel na blogu iOSák.cz, odkud byl převzat se svolením autora. Redakčně upraveno. Pro tento článek neplatí licence CC BY-NC-ND 3.0 CZ, pod kterou publikuje SuperApple.cz, ale zůstává zachována licence původního článku.