kernel: vm_thread_new: kstack allocation failed

Dan Lukes dan at obluda.cz
Thu Feb 14 10:32:26 CET 2019


On 13.2.2019 19:27, Jindrich Fucik wrote:
> Feb 13 03:05:00 stroj kernel: vm_thread_new: kstack allocation failed
> 
> Pokud jsem správně pochopil, má to co do činění s kmem a s diskovým  bufferem. 

To si nemyslim. Podle me jde o kernelovy stack, ktery potrebuje kazdy 
proces. Kod kernelu je v pameti jen jednou a je namapovan do adresniho 
prostoru kazdeho procesu, ale pro svuj beh samozrejme potrebuje i nejaou 
tu pamet, ktera uz musi byt pro kazdy proces samostatna. Tohle je 
selhana alokace kerneloveho stacku pri vytvareni (fork) dalsiho procesu.

> Zdechne v čase, kdy se pokouší zaindexovat všechny soubory a poslat noční status.

To se rozjedou "periodic" tasky, a ty vedou k relativne velkemu mnozstvi 
procesu.

> Tušíte prosím jak tomu stroji pomoci?

Tentokrat nemam cas hledat z jakeho poolu se tahle pamet alokuje a jake 
konkretni duvody mohou vest k tomu, ze se alokace nepovede. Ale 
nejpravdepodobnejsi vysvetleni je, ze tam te pameti proste neni dost. 
Takze tomu stroji nejspis pomuze pridat pamet. Jestli to na tom ARMu jde.

Nejsem si uplne jisty, jestli je tenhle typ pameti swapovatelny. Pokud 
ano, pak by to znamenalo, ze v one chvili uz je plna nejen fyzicka pamet 
ale i swap a pomohlo by jeho zvetseni, ledaze uz je na maximu.

Pokud je neswapovatelna a do stroje nejde pridat fyzickou pamet, tak si 
myslim, ze to nepujde vyresit jinak, nez nejakym laborovanim okolo toho, 
kolik v danou chvili bezi soucasne procesu.

Je tu jeste jedna moznost, ze nedostatek pameti je jen zdanlivy - mozna 
pamet chybi v konkretnim poolu, ale dala by se sehnat v jinem - ale 
takovy presun obvykle nejakou dobu trva (napriklad, kdyz se bere pamet z 
diskovejch bufferu, muze byt potreba nejprve zapsat jejich obsah na 
disk). A pamet vracena jednim procesem se taky musi nejprve vycistit, 
nez ji muze dostat proces jiny. Problem tak muze byt (i) ve "vysokem 
obratu", kdy pameti by mohlo byt dost, ale system ji nestiha "recyklovat 
k pouziti". To by se asi dalo nejak vytunit - velikost rezerv a 
agresitiva cisteni jsou, mam dojem, konfigurovatelne.

Ano, to, ze ti to shodilo celej stroj je nejspis chyba systemu - ve 
skutecnosti samozrejme mel selhat jen ten jeden fork a proces, ktery uz 
se nevejde, by se nespustil. Ale to se bavim jen o tom, ze pricina by 
mel mit jine (mene vazne) dusledky - samotny zakladni problem to neresi.

Tentokrat jsem analyze opravdu venoval mene casu nez obvykle. Vyhrazuju 
si pravo byt naprosto vedle.

Dan





More information about the Users-l mailing list