Vlákno názorů k článku Chrome chce šetřit pamětí, bude sám zavírat nepoužívané panely od Kolemjdoucí - Slušný OS v případě potřeby sám uloží nepoužívanou...

Nekomu kdo tvrdi, ze swap funguje metodou nahodnych zapisu a cteni ???

On to asi myslel prave tak, ze pristup ke swapu neni nahodny, ale pristup ke konkretni strance pameti na disku ano. Pro lidi co nemaji SSD disk to muze byt problem a pride mi, ze casto je rychlejsi natahnout 100 objektu o celkove velikosti 1MB znovu, nez vubec nejakou diskovou cache mit a nebo prepnout na nejakou zalozku po te co byl system uspan.

Nevim jak to vidis ty, ale ja bych teda swapoval vse, co se nepouziva, a zaroven to nechaval v RAMce, dokud tu RAMku neporebuje neco dalsiho. Ale trebas jsou implementatori swapu proste tupci.

Tzn, RAMka by byla k dizpozici, ale zaroven by v zavislosti na jeji velikosti bylo v te RAmce prakticky vse co treba i pokud se to zrovna nepouziva.

Problem browseru je totiz predevsim v tom, ze RAM neuvolnujou, a "spravu" si resej ve vlastni rezii. A to rozhodne neni nejaky nahodny cteni neceho z disku, to je pomerne sofistikovanej pristup, ktere dava slusnou efektivitu a pravdepodonost, ze se neco z toho disku vubec cist bude, je velice nizka. Narozdil od pristupu, ze to na disk ulozim vynucene. A pak to z nej budu samosebou cist ve 100% pripadu.

SSD je porad o nejaky ty rady pomalejsi nez RAMka.

Agresivně odkládat stránky do page file je dobré, pokud je málo RAM. Ale není moudré odkládat vše, protože při jakékoliv operaci v RAM byste změny okamžitě přepisoval na disk. Navíc když je spousta volné RAM (mnohonásobek běžného požadavku na alokaci), tak je swapování celkem zbytečné. Swapovat ano, ale všeho s mírou.

Ad swapování nepoužívaných panelů nebude efektivní - proč by nemělo být?

Ad podobně chaoticky se bude i číst ze swapu - tomu můžete triviálně pomoc tím že stránky označíte pomocí VirtualLock(), kernel je pak ASAP dostane z page file do RAM. Pokud by to nefungovalo, můžete na každou požadovanou stránku sáhnout (nejlépe separátním threadem) a tím způsobit page fault, který stránku dotáhne. Dokonce můžete ovlivnit pořadí, ve kterém stránky budete natahovat.

Když jsem mluvil o náhodnosti, nemyslel jsem, že by kernel swapoval na základě náhodné volby stránek, ale že rozložení přístupů na disk způsobených swapováním se bude chovat dost náhodně se všemi nevýhodami, které z toho plynou.

Jistě že by bylo pěkné navrhnout swapovací algoritmus, který by se takhle nechoval, ale to se zatím nikomu nepovedlo (tedy pokud pominu strategie typu "odswapuj celý proces" přítomné na raných Unixech, které zase měly jiné nevýhody). Na prakticky jakémkoliv OS dneska jednoduché měření ukáže, že swapování je strašlivě neefektivní. [Zejména pokud mluvíme o klasických discích -- na SSD je situace o něco lepší.]

Další problém, na který není radno zapomínat, je, že kernel má od hardwaru jen velmi kusé informace o tom, na které stránky se kdy přistupuje (v zásadě jen jediný bit "přistoupilo se od poslední kontroly stránky"). Skutečná implementace swapování má tedy k nějakému ideálnímu LRU na míle daleko.

Konec konců, stačí si zkusit Chrome nebo Firefox spustit na stroji s 256 MB RAM a spoustou swapu, pootevírat pár tabů a pak si krátit čekání pohledem na zběsile blikající diskovou LEDku ;-)

Netreba zachazet do extremu ... staci si FF spustit v jeho 64bit variante .. a skoro bych rekl ze na libovolnem stroji. Za 3 dny mi nabobtnal na 6GB ... a nevypadal ze by chtel prestat. Jelikoz mel stroj jen 8GB ram, tak jsem jej na zaklade tohoto chovani terminoval jako zcela nepouztelny kram.

Mozna by ke stesti stacilo, proste browseru poslat fake, ze zadna dalsi RAM proste neni a nebude. Idealne nejak snadno uzivatelsky. Proste donutit system, aby mu zadnou dalsi nedal.

Skoda ze jeste nejsem sklerotik ... a pamatuju doby, kdy vecem stacily kB ram a MHz CPU. Na disketu se pak vesly stovky aplikaci.

Tak na to oznameni, ze dalsi pamet neni, by browser nejspis zareagoval jako vetsina ostatnich programu: sel by do kytek - v pripade chromu mozna jen ten tab, ktery si jako posledni o pamet rekl. Prave predpoklad, ze pamet je "neomezena" z pohledu programatora, umoznuje psat programy vyrazne rychleji, a vetsina programatoru vubec neosetruje stav, kdy malloc vrati NULL. On kernel stejne nekdy ten NULL nevrati (treba proto, ze mu jeste trochu pameti zbyva) a nasledne vyvola OOM killer (treba proto, ze tu pamet najednou potrebuje na neco kernel samotny). Navic jakakoliv slozitejsi heuristika v alokacnim kodu kernelu se muze draze nevyplatit na vykonu.

A jeste k tomu swapovani - pokud se udela spravne aplikacni swapovani, tak se serializuje pouze /obsah/ stranky (tj. neco jako zdrojovy kod stranky) a ten se vymrskne na disk. Tedy treba o takovem divu budes mit jen zakladni informaci (v extremnim pripade treba jen uzel v dom stromu), misto toho, abys znal vsechny informace o tom jak je zrovna vyrenderovany na strance (tedy jeho aktualni pozici a velikost, barvu, velikost okraju a spoutu dalsich veci, ktere /ziva/ stranka potrebuje).

A je vas program schopen na OutOfMemoryEx­ception zareagovat tak, aby byl dale pouzitelny? V pripade prohlizece by to znamenalo zruseni operace? Destrukci tabu?

V případě prohlížeče by to znamenalo nutnost uklidit to, co urgentně nepotřebuje, na HDD. Tzn. z tabu zůstane v RAM jenom jeho nadpis a info, kam je uložen. Po překliknutí na něj se takhle uklidí jiný tab/okno...

Nikoliv. To o čem mluvíte je vlastní alokátor (respektive wrapper alokace), ten může v případě chyby zkusit uvolnit paměť (aby mu jí sežral jiný program), zkusit alokaci znova a potom teprve vyhlásit chybu (výjimku). Jakmile je výjimka vyhozena, tak už poslední alokace _selhala_, a musíme se obejít _bez_ ní. (Což v případě, že to je třeba zvětšení struktury udržující DOM, znamená, že jde celý tab do kytek.)

No těch možností je o něco víc. Můžete například vzít paměť ve které držíte nějaký obrázek, použít jí místo toho co jste neúspěšně alokoval, a obrázek označit jako missing.

ses natvrdlej? :) OS nemuze vedet jestli jsou taby delsi dobu TEBOU nepouzivane, pokud si zijou vlastnim zivotem, prohlizec nezna budoucnost, ale nezna ji ani OS, jenomze narozdil od nej, zna prohlizec minulost a soucastnost tabu a to jestl a jak dlouho si ktere taby kdy prohlizel...

Prohlizec ma navic informaci o tom ktera cast pameti (idealne stranka) patri ke kterymu tabu. Jedinou informaci kterou zna kernel je bit, ktery se nastavi pri pristupu procesu ke strance.

Kernel má podstatně více informací o využití stránky, nastuduj si swapování celé.

Přesto nevidím důvod dělat to na úrovni browseru. Když browser tab "odswapuje" ve vlastním formátu, samozřejmě se zastaví skripty které na tabu běží. Proč tedy prostě nezastavit thread nebo proces daného tabu a nenechat příslušné stránky odswapovat na úrovni OS? Pokud uživatel přepne zpátky na daný tab, přijde thradu i procesu event, rozběhne se, a stránky paměti se prostě dotáhnou ze swapu.

Samozřejmě serializace kompletního stavu tabu je dobrá myšlenka. Hodí se to například pro znovu-otevření zavřeného tabu.

V tomto musím souhlasit.

Pokud běží tab jako vlákno nebo proces, není problém poslat mu zprávu / signál a hodit do suspend a uklidit. A klidně se to může udělat na základě toho, že uživatel nerozklikl nějakou dobu záložku (počítám, že streamování rádia dostane v pluginu vlastní vlákno, který se neuspí).

Pokud by swap tabu zabral i s režií 10% výkonu stroje po dobu 100ms a jinak by 20 uspaných a odswapovaných tabů žralo trvale po 2% jednoho jádra, je to sakra rozdíl. Takže přínos to bude.

Ale serializace? Co to přinese? Režii navíc, navíc řešení uklízení v rámci prohlížeče znamená i kód a bugy navíc... Pokud je možnost říct "hele systéme, RAMku proxesu X od adresy Y do adresy Z teď nebudu potřebovat..." Snad jenom pokud si ti exoti vytvoří interně v procesu vlastní heap větší, než data tabu...

Pokud jde o thread, tak "prislusne stranky" predstavuji jen zasobnik (stack). Navic muzete narazit na situaci kdy jedna stranka je sdilena mezi vice taby. To by musel mit browser vlastni virtualni masinu.

Ehm, proč by to měl být jen stack? Heap se přece odkládá do page file úplně stejně. A pokud je stránka sdílená mezi taby a je používaná, tak ji OS do page file neodloží (pokud nedojde na odkládání běžících procesů kvůli nedostatku fyzické paměti, tzv. thrashing).

OS se má starat o běh jádra, grafického prostředí, vlákna a procesy a browser by se měl starat o taby a v tomto případě o cache na odložené taby a systém pouze požádat o zdroj pro tyto operace. Nevidím jediný důvod proč do operací systému s thready a procesy tahat ještě tohle.

Protože kdykoliv aplikace fušuje do činnosti OS tak to dopadne špatně, výjimkou jsou DB servery. Správné chování aplikace je alokovat přesně tolik paměti kolik potřebuje, žádné syslení RAM do zásoby a o tom zda se nějaká paměť bude swapovat nebo nebude si OS rozhodne sám.

Tohle měl kdysi docela hezky vyřešené AmigaOS, ostatně jako ledacos. Škoda ho :)

Mimochodem, viděl jste už nějaký konkrétní návrh podobného mechanismu pro Linux? (Ono to bohužel není triviální, protože se musí notifikace o nedostatku paměti distribuovat v dostatečném předstihu, aby na jejich zpracování ještě byla paměť a nebyly z ní vyhozené kusy kódu, které se mají o obsluhu postarat.)

i kdyz predpokladam ze mluvis o 3.x pro/na m68k, tak AmigaOS 4.1 vysel ani ne pred rokem ;)

Myslim, ze uz tu byly nejake iniciativy implementovat SIGDANGER z AIXu. Ona ale ani ta implementace na AIXu neni kdovi co. Donedavna to umelo jen odwapovavat cele soubory, a navic na AIXu ma kazda stranka predalokovane misto ve swapu uz v momente kdy si o ni proces rekne.

Jj, AIX má SIGDANGER. Předalokování místa ve swapu bylo zrušeno v AIXu 5.1 (rok 2001).
http://www-01.ibm.com/support/knowledgecenter/ssw_aix_53/com.ibm.aix.baseadmn/doc/baseadmndita/page_space_trouble.htm

Ad Donedavna to umelo jen odwapovavat cele soubory - to by mě dost překvapilo. Máte k tomu nějaké další informace?

Aha. Mate pravdu, uz delsi dobu jsem si svoje informace neaktualizoval. Pamatuju si, ze kompilace zdrojaku na AIXu anebo servirovani statickych stranek na Apache byval problem. Bylo to pomaly. Prave proto, ze cachovani na AIXu byvalo mnohem jednodussi nez na Linuxu (na druhou stranu to vzdy bylo i stabilnejsi).

PS: Linux ma (narozdil od Unixu) moznost pri zavolani signalu predat i nejake parametry handleru. Napr. SIGCHILD predava PID procesu.

U Apache na AIXu býval velký problém s multithreadingem, protože multithreading na AIXu měl dost mizerný výkon. Solaris na tom naopak byl podobně jako Windows řady NT. Dnešní situaci neznám.

Ad Linux ma (narozdil od Unixu) moznost pri zavolani signalu predat i nejake parametry handleru - to je praktické, ale chtělo by zahrnout do POSIXu. Ono z hlediska programátora pro UNIX jako platformu není dobré, když se API jednotlivých implementací příliš liší.

sigaction() a siginfo_t v POSIXu samozrejme je. Navic, kdyz uz jde o portabilitu, tak je sigaction() celkem urcite lepsi reseni nez signal().

Ad není shoda na tom, jak to propagovat dál do uživatelského prostoru - stačí se podívat třeba na AIX. Má dva prahy: pokud se dostanete pod paging-space warning level, začne posílat SIGDANGER. Pokud se dostanete pod paging-space kill level, začne odstřelovat procesy které nemají handler pro SIGDANGER. Vyjma toho aplikace mohou voláním psdanger() zjistit rozdíl mezi aktuální volnou pamětí a prahy paging-space warning level a paging-space kill level. A dá se nastavit, že pokud není dost paměti ani po odstřelení procesů bez SIGDANGER handleru, tak se začnou odstřelovat nejmladší procesy které handler mají.
http://www-01.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.genprogc/paging_space_prg_req.htm

Samozřejmě to není dokonalé, protože Memory Overcommitment je v principu špatný nápad.
http://www.oracle.com/technetwork/server-storage/solaris10/subprocess-136439.html

Overcommitment na Linuxu měl primárně řešit situaci, kdy proces tvrdí že potřebuje spoustu paměti, ale ve skutečnosti ji nepotřebuje. Typickým příkladem je fork-exec. Problém je v tom, že kdy slíbíte procesu paměť kterou nemáte, a pak se se té paměti nedostává, tak nemáte jak to procesu říci, a je potřeba něco odstřelit (OOM Killer). Navíc to vede k situaci, kdy se autoři aplikací ani neobtěžují řešit to že alokace paměti selže, protože ta na Linuxu až na extrémní případy vždy projde, a pak je někdo bez varování odstřelen. Vizte výše ten link na Oracle, je to tam pěkně vysvětlené. Implementace "uskrovnění" paměťových nároků procesů je slabá náplast. Lepší než nic, ale chtělo by to alespoň něco takového na Linuxu implementovat. Pokud možno ne moc odlišně od stávajících implementací, protože pro autory aplikací je roztříštěnost UNIXů (nemluvě o distrech Linuxu) už tak dost velká zátěž.

To je tolik kolik aplikace skutečně na něco využívá využívá, žádný garbage collector, prealokování paměti do zásoby, nevracení již alokovaných bloků zpět OS a podobně. Problém není že si aplikace nacacheuje 10 webových stránek do RAM, ale že si jen tak preventivně nasyslí 50 MB pro každý tab.
btw. Stránka natahá cca 5 MB z internetu, vykreslená bitmapa cca 800*3000px má pouhých 10 MB, tak proč do pr*** celý tab žere 100 MB ?

Ad Stránka natahá cca 5 MB z internetu, vykreslená bitmapa cca 800*3000px má pouhých 10 MB, tak proč do pr*** celý tab žere 100 MB - na prvním místě potřebujete executable jako takový. Potom musíte HTML nacpat do paměťových struktur umožňujících random access. DOM potřebuje cca 10x více paměti než zdrojové HTML. Nevím jestli se informace o vizuálních objektech skladují v DOM nebo zvlášť, ale ty objekty mají spoustu vlastností které nejsou v zdrojáku stránky (všechny properties které jsou podporované ale nejsou uvedené na stránce), nebo nejsou vůbec součástí HTML (například informace o zlomu textu), a určitě to také strojí dost paměti. K tomu většina stránek obsahuje skripty, což znamená izolovanou instanci nějakého JS engine, který dneska typicky obsahuje i nějaký kompilátor. Pak musíte vyrastrovat všechny prvky na stránce, některé vícekrát (například animované gify).

Jo a koukal jsem kolik si vezmou procesy MSIE a Firefoxu.
MSIE (process-per-tab):
- Base process 9MB
- Tab http://www.msftncsi.com/ncsi.txt 10MB
- Tab http://www.idnes.cz/ 42MB + 3MB proces Adobe Flashe

Firefox (single process):
-Tab s http://www.msftncsi.com/ncsi.txt 116MB
- Když přidám tab s idnes.cz tak 160MB + 9,5MB dva procesy Adobe Flashe (nevím proč dva).

V obou případech jsou browsery bez doplňků, Chrome nemám. Řekněme že Firefox nejspíš není úplně vzor úspornosti.

Obecněji je problém v tom, že se snažíme z webového browseru za použití hromady skriptů dělat aplikační platformu. Sice webové aplikace pořád nedokážou to co desktopové aplikace před dvaceti lety, ale náročnost na RAM a CPU je už dávno nesrovnatelně vyšší.

Mimochodem, DOM je sice obrovský, ale velmi redundantní. Jelikož většina properties je prostě zděděná z nadřazeného objektu, šel by nejspíš velmi efektivně komprimovat. Netušíte, jestli to už někdo zkoušel?

Osobně jsem to nezkoušel, anle několik myšlenek, jak to udělat, bych měl. A není to nic složitýho...

Řešil bych to per-page, nikoliv per-thread/process. Když thread/process čeká na událost, nesahá na svá data v heapu. Tyto stránky jsou pak LRU, a kernel je zkopíruje do page file. Pokud paměť potřebuje jiná aplikace, tak kernel odloženou stránku přidělí té aplikaci namísto browseru. Navíc jediná změna potřebná na straně browseru je zastavení threadu/procesu, který se o tab stará.

U thread-per-tab modelu samozřejmě v heapu mohou být skončit informace z různých tabů v jedné page. To ale asi bude poměrně výjimečné. Podle nějakého článku na zive.cz (link v diskusi níže) si FF řekne o 50MB RAM jen pro renderer. Tahle paměť, stejně jako DOM, bude poměrně souvislá.

Ad se dostáváme k něčemu podobnému, jako je klasické swapování - ono to je klasické swapování, modifikované jen tím že když tab není nějakou dobu na popředí, tak se zastaví. Se zbytkem si poradí OS.

Ad pokud se budou mixovat alokace jednotlivých vláken, tak to, zvlášť u dynamických stránek, až tak souvislé být nemusí - samozřejmě to není 100% čistý řez, ale to ani není potřeba.

Ad jestli thread-per-tab je vhodný model. Na některé věci (napadá mě I/O) by stačilo jedno společné vlákno. Na řešení událostí, no, to je dost otázka - zrovna I/O musí být řešené multithreadově/a­synchronně. Jinak se vám jeden request sekne čekáním na timeout, a všechno kvůli tomu bude stát. Podobně rastrování musí být multithreadové. Jinak se vám na jednom tabu bude pomalu rastrovat stránka plná čínského textu, a všechno ostatní kvůli tomu bude stát.