Administrace komentářů

pokud neni swap, docela snadno se stane, ze se kcompactd vubec nedostane ke slovu pro proaktivni compaction, protoze je system tak nejak v permanentnim reclaimu (kswapd_is_running) - a tak je system v kolecku, ze aby bylo kam davat ty anonymni stranky pro nove spousteny procesy, musi se neco uvolnovat - no a ty procesy pak vzdycky znova dozapraskaji zbytek volna skrz pagecache, cim si to akorat rekne o vic reclaim prace za nedlouho v budoucnu... takze kdyz pak prakticky nebezi kcompactd a jsou potreba vetsi bloky souvisly fyzicky pameti, budto se je povede ziskat primo v ceste alokace, nebo smula - a tam to pak zdrzuje aplikaci, nejdriv pokus o compact, pak pokus o reclaim... a kdyz pak konecne dojde na fail pri kmallocu vetsi velikosti, jeste nedavno se to projevovalo ruznou nefunkcnosti ruznych subsystemu, dokud se vsechny ty callsites nepredelaly stylem whack-a-mole na kvmalloc, kdy se po jednom neuspesnym roundu reclaimu pouzije vmalloc, kdyz nevyjde primo kmalloc... poznat takovy system jde docela jednoduse, poznavaci znak cislo jedna je relativne vysoky loadavg (a volny CPU cas) a potvrzeni prijde, kdyz si catnes /proc/buddyinfo a krom prvnich par sloupcu jsou vsude konstantne nuly, tak to je pak presne tahle situace

pritom system muze hlasit klidne 10% volny pameti, co na 2T masine je klidne tech 200G volnych, ale alokace vyssich radu failujou uplne a nez se to dostane k mensim tak proste proces stoji...

uplne nejlepsi je dat takovymu systemu zram-backed swap, protoze zram umi pracovat se 4k pages, nepotrebuje vetsi, akorat tak o velikosti tech 10% RAM... samozrejme tohle cely je poznat jenom, kdyz se na tom systemu deje neco s dostatecnou intenzitou, kdyz je to idle, tak nemaji, proc tam byt nejaky tlaky...

a btw, uz jenom pouha pritomnost swapu o velikosti jedny jediny stranky meni zasadne kalkulace pameti/watermarku, viz git grep get_nr_swap_pages, ma to docela velky vliv na vypocet working set size