OOM killer - MOCKUP

7.1.2010 11:50 | Přečteno: 1665× | poslední úprava: 7.1.2010 11:53

Jelikož používám Linux na Alixu, kde je málo paměti(256 MB RAM + 256 MB Swapu na CF kartě), tak mě napadlo jedno vylepšení OOM killera.

Na Vánoce jsem si totiž koupil externí disk a to mě přimělo k nápadu jak by mohl fungovat OOM Killer na podobných embedded zařízeních. Leč nejsem linux kernel programátor, tak zůstane jenom u nápadu: ;(

Prozatím co je mi známo, tak když začne docházet paměť, tak OOM killer ukončí podle nějakého algoritmu určitou aplikaci. Mi by se docela líbilo, kdyby ještě předtím zkontroloval seznam tzv. záchranných SWAPů(mohl by být třeba definovaný zápisem do nějakého souboru v /proc, nebo /sys), nebo SWAP souborů a v případě, že je nějaký takový definovaný, tak by jej nejprve připojil, čímž by rozšířil dostupnou paměť v systému a zabránil tak pádu aplikací. A když by se zase paměť uvolnila, tak by se záchranný SWAP zase odpojil.

Ještě lepší by bylo, kdyby šlo u záchranných SWAPů, definovat prioritu.

A jak to souvisí s diskem, který jsem si koupil k Vánocům? Jedná se totiž o NAS disk ZyXEL a mít trvale připojený SWAP soubor na nějakém zařízení připojeném přes síť, by asi nepřineslo dobrou výkonnost, ale v případě nouze by mohlo celkem dobře posloužit. ;)

Na závěr ještě přidám malou anketku. Myslíte si, že se jedná o zajímavý nápad, nebo hloupost?

       

Anketa

Komentáře

[hajma]

No, ja bych si predstavoval, ze v pameti bude permanentne pritomna mala (<1MB) aplikace, ktera pri OOM prebere iniciativu, zastavi vsechny IO, vyplivne na mne okno s procesy poskladanymi podle zabrane pameti a dovoli mi je zabit.

[filbar]

To je taky dobrý nápad. V zápisku jsem ale spíše myslel na situace bez GUI, kde by se bez uživatelova zásahu připojil záchranný SWAP a systém by "nespadnul".

[Luk]

Ale mohlo by to být řešeno jako aplikace. Kdysi jsem uvažoval o vytvoření aplikace, která by běžela s vysokou prioritou a která by (např. každou sekundu) kontrolovala využití swapu. Pokud by překročilo definovanou mez (např. 75 %), připojila by další swap, třeba i vzdálený, který by měl nižší prioritu než normální swap. Při poklesu využití swapu by nový prostor případně po nějaké době zase odpojila. Implementace je vcelku triviální, problém je ale v tom, že ten swap musí být předem připraven (nelze v časové tísni spouštět mkswap), takže někde zabírá místo.

[Josef Kufner]

Příloha:

• auto-swap.sh (918 bytů)

Jo, tohle už pár měsíců celkem spokojeně používám. Obvykle swap nepotřebuju vůbec a systém je bez něj svižnější. Pokud ale paměť dochází, při troše štěstí se sám připojí.

[Heron]

Což by se u vzdáleného systému přinášelo další radosti administrátorům.

[hajma]

to by mne na desktopu ale vubec netrapilo, tam je mi naopak na houby presmerovani na seriovy port.

[l4m4]

Zastavit I/O a vyplivnout okno s procesy se navzájem vylučuje.

[hajma]

samozrejme zastavit io tech procesu, pokud to tedy jde. protoze v okamziku, kdy se zacne dit poradny thrashing, se se systemem neda delat skoro nic

[zelial]

Druhemu swapu na externim disku nastav nizsi prioritu (man swapon), pripadne si jeste pohraj s /proc/sys/vm/swappiness, a nemelo by vadit, ze je trvale pripojeny.

[Josef Kufner]

Spíš než tohle by to chtělo, aby se swap nepoužíval, dokud není potřeba a více se kašlalo na IO cache/buffery. V současné době se klidně odswapuje půlka desktopu jen kvůli zkopírování filmu mezi disky... Obzvlášť chuťovka je to při přesunu takového filmu, kde se hezky poctivě nakešuje a pak se z cache vyhodí, protože zmizel z disku. Výsledkem je prázdná paměť a všecko odswapované.

[Jendа]

Nemělo by to jít poladit pomocí swappiness zmíněné o jeden příspěvek výše?

[Josef Kufner]

Ne, swappiness prakticky nefunguje a navíc dělá něco úplně jiného.

[Käyttäjä 11133]

SWAP over NFS? :D

[filbar]

Myslím SWAPfile

[Käyttäjä 11133]

Jo to mi došlo, já jen... poslední dobou vidím všechno over NFS... Oracle over NFS, SAP over NFS, VMWare over NFS,... :)

[Kvakor]

Nebo Swap over NBD, ale narozdíl od postupu v návodu doporučuju předhodit ndb-serveru jen prázdný děravý (sparse) soubor, popř. partition, a mkswap udělat až na straně klienta. U rozdílných architektur či bitovostí je to nutnost.

[CET]

No nevim, mam dojem, ze jsem casto videl OOM a swap byl prazdnej. Nevola se OOM pouze v pripade, ze dochazi fyzicka pamet a nic se z ni neda hodit na swap? Pak by ta myslenka byla docela na nic. Aspon perl, kterej pouziva na stringy pouze RAM, se pri dlouhym stringu (napr. $a="x"x(1024**4); zhrouti s Out of memory hlaskou a nic se neswapne.

[Luk]

Nevola se OOM pouze v pripade, ze dochazi fyzicka pamet a nic se z ni neda hodit na swap?

OOM killer se spouští skutečně jen v případě, že dochází fyzická paměť a nelze žádnou uvolnit. Ale to je právě typicky případ vyčerpání swapu, protože jsou v paměti neaktivní anonymně mapované stránky, které není kam odložit.

Není mi jasné, jak by mohl Perl "používat pouze RAM", pokud by si předem nezamkl příslušné stránky v paměti, aby nemohly být odloženy. A nemyslím si, že si při každé stringové operaci ty stránky zamyká a pak je zase odemyká.

[podlesh]

"Out of memory hláška" není OOM killer.

[Luk]

Zřejmě to vypadá na vyčerpání adresního prostoru, protože sice nejsem perlař, ale 1024**4 je asi 1024*1024*1024*1024, tedy 1 TB. To se do 32bitového prostoru opravdu nevejde. Pokud by to bylo na 64 bitech, pak by to zřejmě swapovalo jak ďábel a nakonec by se aktivoval OOM killer. Samozřejmě za předpokladu, že by nebyl nastaven resource limit na virtuální paměť procesu (pokud by nastaven byl, mohl by být proces ukončen ještě před vyčerpáním paměti).

[Radovan Garabík]

Kedysi veľmi dávno, keď ma veľkosť disku trápila, som na niečo podobné narazil... <google>.... http://cvs.linux.hr/swapd/

[Jumper]

Zjova, vsimli jste si, ze autor ma v blogu obrazky webkamery? Nic drsnejsiho jsem jeste nevidel!

[default]

Prozatím co je mi známo, tak když začne docházet paměť, tak OOM killer ukončí podle nějakého algoritmu určitou aplikaci. Mi by se docela líbilo, kdyby ještě předtím…

…skočil do krámu a dokoupil RAMku. A na závěr uvařil kafe.

Takhle by se to líbilo mně.

[filbar]

Mi taky, jenomže třeba na tom Alixu je paměť dána natvrdo a nejde jí tam přídávat/odebírat.

[Grunt]

kde je málo paměti(256 MB RAM + 256 MB Swapu na CF kartě)

LOL, taky dobrý.

Prozatím co je mi známo, tak když začne docházet paměť, tak OOM killer ukončí podle nějakého algoritmu určitou aplikaci.

On neukončí podle nějakého algoritmu určitou aplikaci, ale snaží se nalézt aplikaci, která najednou sežrala co nejvíc paměti (např. aplikace které se ve smyčce zaseklo alokování paměti a tak bude alokovat do nekonečna – taková aplikace si ani nic jiného než smrt nezaslouží). A ještě takové aplikaci dopřávat více místa? Mně to teda přijde pěkně padlé na hlavu. Jinak kvůli tomu není potřeba vymýšlet znova kolo:

dd if=/dev/zero of=/lokalni/swap/v/souboru.img bs=1M count=100
losetup /dev/loop0 /lokalni/swap/v/souboru.img
mkswap /dev/loop0
swapon /dev/loop0

A po použití:

swapoff /dev/loop0
losetup -d /dev/loop0
rm /lokalni/swap/v/souboru.img

Akorát mě teda opravdu nenapadá rozumný příklad použití něčeho takového. Něco podobného dělá Windows.

[Luk]

A ještě takové aplikaci dopřávat více místa? Mně to teda přijde pěkně padlé na hlavu.

Padlé na hlavu to není. Někdy se stává, že nějaká aplikace potřebuje dočasně opravdu hodně místa, protože se s ní prostě pracuje tak, že má velké paměťové požadavky (stačí se třeba otevřít nějakou webovou stránku, na kterou někdo naházel hromady fotek přímo z 12Mpx foťáku nebo tam narval extrémně prasácký Flash). Standardně by nastalo to, že by se spustil OOM killer a pravděpodobně by sestřelil právě tuto aplikaci (není to ovšem úplně jisté, algoritmus může dojít k jinému soudu). Jenže ještě před spuštěním killera by se jádro snažilo usilovně získat jakoukoli paměť, která je získatelná, což může zabetonovat systém na desítky sekud až minuty. V souvislosti s někdejší interakcí mezi Operou a X serverem (kdy X server kvůli Opeře zběsile alokoval paměť - lze to najít v mém blogu několik let zpátky) jsem ohledně tohoto načerpal docela slušné praktické zkušenosti.

[Grunt]

Padlé na hlavu to není. Někdy se stává, že nějaká aplikace potřebuje dočasně opravdu hodně místa, protože se s ní prostě pracuje tak, že má velké paměťové požadavky

Padlé na hlavu to je. Pokud se tak aplikace chová, tak to jen značí to, že je aplikace špatně navrhuntá a pak si nezaslouží nic jiného než přepis a nebo výmaz z disku. V 99% případů jde jakýkoliv algoritmus přepsat tak aby nepotřeboval sežrat veškerou paměť počítače.

Příklad ze včerejška: Potřeboval jsem zprůměrovat přibližně 400 obrázků pomocí ImageMagicku, tak prostě z pohodlnosti jsem napsal: convert *.png -average avg.png. Dostal jsem se k něčemu podobnému. Všech 400 obrázků o rozlišení 640x480 se načetlo a rozbalilo do paměti a zbobroval jsem na něčem podobném. Ale ani za boha by mě nenapadlo navyšovat dočasně velikost swapu nebo obviňovat autory ImageMagicku z diletantství. Ten diletant jsem byl já, protože správně to mělo být mv 0000001.png avg.png && for a in 0000*.png; do convert avg.png $a -average avg.png;done. Toť vše co se snažím říct.

stačí se třeba otevřít nějakou webovou stránku, na kterou někdo naházel hromady fotek přímo z 12Mpx foťáku nebo tam narval extrémně prasácký Flash)

O webech s 12Mpix fotkami nebo prasáckým flashem si myslím své a takové si IMHO rozšiřování swapu rozhodně nezaslouží.

Jenže ještě před spuštěním killera by se jádro snažilo usilovně získat jakoukoli paměť, která je získatelná, což může zabetonovat systém na desítky sekud až minuty.

Pravda. Tady je chyba. Taková aplikace si zaslouží byt zabita ještě mnohem dříve.

[default]

Pokud se tak aplikace chová, tak to jen značí to, že je aplikace špatně navrhuntá

Eclipse a jeho úžasné SWT mi naleakovalo denně 400 MB v X-Serveru.

a pak si nezaslouží nic jiného než přepis

Já budu přepisovat Eclipse a X-Server. Jasněéé! Hurá do toho.

a nebo výmaz z disku.

Přesně tohle jsem udělal.

[Grunt]

Já budu přepisovat Eclipse a X-Server. Jasněéé! Hurá do toho.

Pokud to byla chyba X-Serveru, tak místo kvíkání aspoň bug report by vhodný byl. Eclipse neznám, takže se k němu vyjadřovat nebudu. Ale určit která aplikace si to zaslouží a která ne není tak jednoduché jak tady popisuju. SIGSTOP a nech si uživatel rozhodne jestli si to zaslouží nebo ne.

[Grunt]

No dobře, možná jsem to trochu přehnal. Je dost možné, že aspoň zazipovaný core dump by si zasloužil.

[Václav HFechs Švirga]

Vrahuuuu!

[Grunt]

No?

[Heron]

V 99% případů jde jakýkoliv algoritmus přepsat tak aby nepotřeboval sežrat veškerou paměť počítače.

To je ovšem klasické dilema. Rychlost/paměť. I pro ten tvůj případ by mělo být rychlejší těch 400 fotek natlačit do paměti a tam je naráz zpracovat, než 400x ukládat nějaký dočasný soubor a 400x pouštět nový proces.

[trekker.dk]

Nemluvě o tom, že je otázka, jestli zprůměrovat 400 souborů je to samé jako zprůměrovat dva, do něj třetí, do výsledku čtvrtej atd.

[Grunt]

Vždyť to jsem dělal. I s pamětí je to vyřešené, protože avg.png je nakešovaný a stačí pouhý mmap. A kdyby to nestačilo, tak stačilo umístnit avg.png do nějakého tmpfs. A to je také to co jsem se snažil říct.

[Grunt]

A úplně nejlíp bych to vyřešil s avg.miff.

[Grunt]

Ne, není. Jestli se jich všech čtyři-sta natlačí do paměti a pak zpracuje a nebo se načítají postupně jedna za druhou a přidávají se postupně k průměru je úplně jedno. Vlastně není. Druhý algoritmus je mnohem lepší, protože sežere paměť o velikosti dvou obrázků a bude úplně stejně rychlý (možná jen o zanedbatelnou kapičku pomalejší). Proto jsou algoritmy jako JPEG nebo MP3 tak populární. Doporučuji se podívat na jejich referenční implementace. Je to opravdu jen pár statických proměnných (určitě by se dali spočítat na prstech dvou ruk) a malinkatý statický buffer (v případě JPEGu je obraz rozdělen na dále nedělitelné bloky o 64 pixelech, které se sekvenčně zpracovávají a v případě MP3 je to frame o 1152 vzorcích). A ještě se to dá zpracovat v reálném čase s malou prodlevou.

[Jendа]

určitě by se dali spočítat na prstech dvou ruk

K 1023 se to snad nepřibližuje.

[Grunt]

A MPEG na tom není o moc jinak. A FFTW dokonce dovede transformaci spočítat na tom poli vstupních dat.

[trekker.dk]

Jestli se jich všech čtyři-sta natlačí do paměti a pak zpracuje a nebo se načítají postupně jedna za druhou a přidávají se postupně k průměru je úplně jedno.

Tak to samozřejmě není. Jestliže se opravdu jedná o průměr, pak se při osmi bitech na barevný kanál a postupném přidávání nemusíš vůbec obtěžovat s importem prvních cca 390 fotek.

[Grunt]

No, to je fakt. Byla to dramatizace. Lepší příklad mě hned nenapadnul.

[quik]

Teda nevim, co ma to "convert -average" presne delat, ale pokud by to byla analogie pocitani aritmetickemu prumeru, pak

(((((a_1 + a_2) / 2) + a_3) + ...) + a_n) / 2 != (a_1 + a_2 + ... + a_n) / n

[Grunt]

No, už jsem si všiml(platilo to u operace -compose Plus, jsem to opsal a jen to zaměnil za -avg a víc nad tím nepřemýšlel) . Ale určitě by to šlo vyřešit nějakým chytrým algoritmem u kterého by nebylo nutné jich všech 400 cpát do paměti. Už mi jen zbývá přijít na to jakým.

[Heron]

Přemýšlel jsem ještě nad jiným problémem. Aby toto "iterováni" fungovalo, musel by se mezivýsledek ukládat do formátu s mnohem vyšší bitovou bloubkou na kanál než požadovaný výstup. A to k vůli zaokrouhlovací chybě.

Pokud mi to po probuzení nagiosem správně myslí, tak mezivýsledek operace průměr (nějaké iterovatelné verze) je obecně reálné číslo a je nutné je zaokrouhlit na celé. Tj. zde se vnáší chyba 0.5. Pokud by se to ukládalo do 8b na kanál, je zde 256 různých hodnot a pro 400 iterací by velikost možné chyby narostla na 200. A výsledek Red=80(+- 200) by ti byl asi k ničemu (statisticky přesně to počítat nebudu).

Šlo by to vyřešit tak, že by se jednotlivé vstupní obrázky sečetli do něčeho s 32b na kanál a pak se to podělilo a zaokrouhlilo na konci.

[Grunt]

Přemýšlel jsem ještě nad jiným problémem. Aby toto "iterováni" fungovalo, musel by se mezivýsledek ukládat do formátu s mnohem vyšší bitovou bloubkou na kanál než požadovaný výstup. A to k vůli zaokrouhlovací chybě.

Mám zkompilovaný ImageMagick se parametrem --enable-hdri, který funguje ve floating-point a dovede zpracovávat až 96-bitové TIFFy. Mezivýsledky ukládám do interního formátu ImageMagicku s koncovkou miff, který většinou stačí jen namapovat. Ale stejně je rozptyl tak veliký, že nějaký kvantizační šum od 8-bitů je jen pakatel.

[stativ]

Jak jsem psal níže, jde použít tzv. provisional means (OT: používá se v ČJ dočasné průměry nebo něco jiného?). Průměr se pak počítá m_{k+1} = m_k + (x_{k+1} - m_k) / (k+1), kde m_k je průměr prvních k-čísel

[Grunt]

Jo, díky. Určitě se to někdy bude hodit.

[stativ]

To je fakt, pak by se na to musel použít algoritmus "Provisional means".

[Mrkva]

Jenže ještě před spuštěním killera by se jádro snažilo usilovně získat jakoukoli paměť, která je získatelná, což může zabetonovat systém na desítky sekud až minuty.

Když má člověk vypnutý swap, tak je vzpamatování se systému z nedostatku paměti záležitost pár vteřin.

[Ondrej 'SanTiago' Zajicek]

To neni uplne pravda, pokud nemas swap, tak je situace paradoxne horsi. Pokud mas swap a dojde pamet, tak system zacne odkladat nepouzivane stranky na disk, coz system trochu zpomali, ale zas uvolni dost pameti, takze se se systemem jeste da pracovat. Pokud ale swap neni, tak system zacne uvolnovat pamet zahazovanim stranek, ktere je mozne znova nacist z disku - tedy napriklad stranek, ve kterych je ulozen spustitelny kod bezicich programu. A protoze tech zas tolik neni, tak to postihne a dost zpomali cely system.

Striktne vzato, vzpamatovane se systemu z nedostatku pameti pote, co OOM killer vinika zabije, rychle bude. Ale nez k tomu dojde, tak tam je prave ta zabetonovaci faze. A jak dlouho v ni system zustane zavisi v podstate akorat na tempu dalsi alokace.

Mozna by bylo dobre, kdyby kernel poustel OOM killera uz v okamziku, kdyz by detekoval signifikantni trashing, nikoliv az v pripade, kdy uz opravdu nejde dal alokovat pamet.

[Mrkva]

No, ve chvíli kdy pustím klasickou Cčkovou hračku for(;;) malloc(1024**2); tak se systém paradoxně chová líp bez swapu - pokud to spustím bez swapu, OOM killer proces odstřelí a po pár vteřinách je klid. Ale se swapem (ok, 5400RPM notebook disk) bude systém zaseknutý během doby, kdy se to bude snažit odswapovat (řádově minuty) a pak (protože to ten proces stejně zabije) bude systém stát znovu kvůli tahání dat zpět do RAM.

[Grunt]

Dřív se dokonce systém snažil defragmentovat paměť. To teprv bývalo něco.

[Ondrej 'SanTiago' Zajicek]

No, ve chvíli kdy pustím klasickou Cčkovou hračku for(;;) malloc(1024**2); tak se systém paradoxně chová líp bez swapu

To je kod ktery pravdepodobne alokuje dalsi pamet prilis rychle, takze ona faze mezi tim, kdy prakticky dojde pamet, a nez se spusti OOM killer, je prilis kratka (i kdyz je otazka, jakou rychlosti ten kod tu pamet vlastne alokuje - samotny malloc 1 MB by toho moc realne alokovat nemusel, pokud se na ty stranky nepristupuje. Doporucil bych tam pridat jeste smycku, co na kazde 4 kB zapise nejakou hodnotu).

U realnych programu, ktere alokuji pamet pomalu a nejak s ni opravdu pracuji, je ten prubeh jiny. Sam na svem pocitaci swap nemam, tak s tim mam par zkusenosti. :–)

[Luk]

samotny malloc 1 MB by toho moc realne alokovat nemusel, pokud se na ty stranky nepristupuje. Doporucil bych tam pridat jeste smycku, co na kazde 4 kB zapise nejakou hodnotu

Ano, pouhý malloc() u typického systému (výchozí nastavení, tj. s memory overcommittingem) nezpůsobí alokaci paměti, protože příslušné volání brk() jen přidá položky do tabulky stránek. K vlastní alokaci dojde až při přístupu do té paměti.

[Mrkva]

Pokud se nepletu, není ani nutné spouštět losetup - myslím, že akceptují i běžný soubor.

[Grunt]

No jo, to jsem ani netušil.

[Grunt]

Ale zas tak růžové to také není:

Note that a swap file must not contain any holes.

Ale přiznávám, že překládat pozici na disku pomocí loop zařízení je ještě debilnější než vůbec mu takový soubor přidělovat. (Nemam tolik spojitého volného prostoru na disku)

[Josef Kufner]

Ehm... nejde o spojitý soubor, ale o neděravý. dd bez parametru skip a swapon bohatě stačí.

[Kvakor]

Ano, losetup není nutný, swaponu stačí i soubor.

A na ovlivnění OOM killera tu v novýějších jádrech existuje parametr oom_adj, který ovlivnuje, a oom_scrore, který ukazuje aktuální stav. Viz dokumentace:

2.12 /proc/<pid>/oom_adj - Adjust the oom-killer score

This file can be used to adjust the score used to select which processes shall be killed in an out-of-memory situation. Giving it a high score, increase the likelihood of this process being killed by the oom-killer. Valid values are in the range [-16:15], plus the special value '-17', which defeat the oom-killer altogether.

2.13 /proc/<pid>/oom_score - Display current oom-killer score

This file can be used to check what the current score used by the oom-killer is for any given <pid>. Use it together with /proc/<pid>/oom_adj to tune which process will be killed in an out-of-memory situation.

Takže není problém OOM killera ukecat pomocí velkého záporného oom_adj, případně ho zcela zažehnat hodnouou -17.

[Mrkva]

Takže chápu dobře, že stačí dát mému procesu oom_adj=-17 a nechat ho leakovat a OOM killer pozabíjí celý systém, aby můj leakující proces mohl v klidu běžet? Nádhera!

[JS]

Me by se obecne spis libilo, kdyby jadro trochu vice komunikovalo s procesy ohledne vyuzivani zdroju. Soucasne operacni systemy jsou navrzene nekooperativne - prideluji zdroje mezi procesy direktivne, bez ohledu na to, co ty procesy zrovna delaji. Bylo proste pekne, kdyby jadro mohlo procesu rict, tak, ted bych potreboval, aby se tento proces trochu uskrovnil ohledne vyuzivani nejakeho zdroje (treba pameti, ale mohlo by jit i o cokoli jineho, treba o uvolneni nejakeho zamku), a ten proces na to umel zareagovat (treba spustit garbage collection, vyprazdnit nejake cache, a tak dale).

V mnoha pripadech totiz rychlost algoritmu zavisi na mnozstvi dostupne pameti. Bylo by daleko lepe, kdyby se proces mohl (prubezne) informovat, kolik pameti asi tak muze pouzit, a na zaklade toho upravil svuj algoritmus.

[Grunt]

Nevím. To mi osobně přijde až moc komplexní. A proč by se měl systém starat o to jak proces použije alokované místo? Když o něj proces žádá, tak ho asi potřebuje a když ne, tak ho uvolní, ne? By mě zajímalo s jakou odezvou bych se setkal, kdybych něco takového navrhnul v reálném světě.

[lareen]

JS chce nejspis rict, ze neni pravda, ze kdyz zada, tak potrebuje. S vetsim mnozstvim dostupne pameti by treba mohl bezet rychleji (mezi vysledky si muze napr. cachovat v pameti nebo znovu dopocitat). Proces ale nevi, o kolik si muze rict, aby to nebylo sobecke.

Nicmene se mi nezda, ze by toto nutne muselo ridit jadro.

[Grunt]

JS chce nejspis rict, ze neni pravda, ze kdyz zada, tak potrebuje. S vetsim mnozstvim dostupne pameti by treba mohl bezet rychleji (mezi vysledky si muze napr. cachovat v pameti nebo znovu dopocitat). Proces ale nevi, o kolik si muze rict, aby to nebylo sobecke.

To ale v žádném případě není starost nikoho jiného než programátora. To by mělo jako jádro rozhodovat jestli to místo které proces žádá ho opravdu potřebuje? To je především starost programátora, ne? Vím že neznalost a lenost programátorů řeší prostě rychlejším HW(je to levnější), ale ještě aby jejich problémy řešilo i jádro systému? Co by ti programátoři, resp. analytici a softwarový inženýři vůbec ještě dělali kdyby to za ně řešili všichni ostatní? Váleli se na Bahamách?

[lareen]

Ne, stale tomu nerozumis. Nekomu nevadi, kdyz program pobezi pomaleji nebo bude vic narocny na cpu, pokud spotrebuje malo pameti, nekdo jiny muze chtit, aby program bezel, co nejrychleji, a nevadi mu, ze bude pametove narocnejsi. Rict tohle staticky dopredu je malo, protoze v prvnim scenari bude program bezet zbytecne pomalu i v pripade, ze je momentalne dostupna spousta pameti, o kterou nikdo nestoji.

[JS]

Ano, presne tak. I kdyz ono i dnes je obtizne to aplikacim rict staticky dopredu; vetsina aplikaci je napsana tak, ze zkratka predpoklada urcite mnozstvi pameti a ani se nejak nepocita s tim, ze by se na to mohly (jejich algoritmy) adaptovat. Takze nejaka dynamicka adaptace je hudba vzdalene budoucnosti.

Chapu, ze to muze byt slozite, ale dostat maximalni vykon z neceho je vzdycky slozite. Zatim neumime jednoduse programovat zpusobem, ktery by uvedeny postup dovoloval.