FreeBSD 12 + mfs root - panic no memory to grow kernel

[Mira Chlastak]

Tak jsem konecne dolaboroval a uz to opet funguje. Opravdu jsem musel kernel buildnout s upravenou hodnotou NKPT (puvodne NKPT=42, nyni jsem na NKPT=88 - nejnizsi hodnota co s velikosti meho MFSROOT nabootuje).

Moooc dekuji za spravne nasmerovani a snad to nekdy nekomu taky pomuze :)

--
Mira Chlastak

----- Original Message -----
Od: "Dan Lukes" <dan at obluda.cz>
Komu: "FreeBSD mailing list" <users-l at freebsd.cz>
Odeslané: Sobota, 26. Leden 2019 12:57:55
Předmět: Re: FreeBSD 12 + mfs root - panic no memory to grow kernel

On 25.1.2019 17:52, Mira Chlastak wrote:
> Diky za popis. Rozdeleni pameti pro KERNEL a "others" beru v potaz. Jen nevim, cim presne se to urcuje (kmem_size??)

Driv se to (alespon u i386 kernelu) urcovalo primo pri prekladu. Priznam 
se, ze jak je to dneska, a navic na amd64 kernelu, nevim.

Neni uplne vylouceny, ze tohle na amd64 potreba neni - preci jen, i386 
(bez PAE) melo 4GB adresovatelne pameti. Take kazdy proces se do tohohle 
musel vejit, vcetne adresniho prostoru pro kernel - tam to byla trochu 
honicka to rozdelit aby se vesel kernel a pritom zustal nejaky rozmny 
prostor i pro uzivatelskou pamet.

Na amd64 ma linearni adresu 48bitovou (v nejnovejsich procesory s 
petiurovnovym pagingem dokonce 57bitovou). Po uplne letmem pohledu do 
zdrojaku se mi zda, ze na amd64 se pro kernel vyhradil 2TB prostor 
linearni pameti (VM_MIN_KERNEL_ADDRESS - VM_MAX_KERNEL_ADDRESS) zcela 
napevno, pod heslem "to nemuze dojit".

vm.kvm_size je read-only sysctl, ktere vraci prave 
(VM_MAX_KERNEL_ADDRESS - VM_MIN_KERNEL_ADDRESS) tedy cca 2TB

To samozrejme neznamena, ze do celeho tohohle linearniho prostoru je 
namapovana nejaka fyzicka pamet (tolik ji vetsinou v pocitaci ani neni) 
- ve skutecnosti je pro kernel pouzitelna jen pamet od 
VM_MIN_KERNEL_ADDRESS do kernel_vm_end

vm.kvm_free je read-only sysctl, ktere vraci kolik jeste zbyva volne 
(VM_MAX_KERNEL_ADDRESS - kernel_vm_end)

pmap_growkernel posouva hodnotu kernel_vm_end, jinymi slovy, zvetsuje 
kernelovy linearni pametovy prostor, do ktereho realne je namapovana 
nejaka fyzicka pamet (a tudiz ho lkze pouzivat). Takze posun 
kernel_vm_end neni jen prepsani te hodnoty, ono je treba "naalokovat" 
(vm_page_alloc) fyzickou pamet a namapovat ji do linearniho adresniho 
prostoru. pmap_growkernel zpanikari pozorovanym zpusobem prave tehdy, 
kdyz selze ten vm_page_alloc

No, rozbor mozna peknej, ale nemyslim, ze te prilis posune k reseni. 
Nevidim zadny zjevny duvod, proc by alokace stranky (stranek) mela 
selhat - ledaze pamet pro preloaded MFS se alokuje jeste pred tim, nez 
je VM system naincializovanej a system tam ma k dispozici jen stranky 
prealokovane pri bootstrapu.

To by vysvetlovalo, proc to pada u preloaded MFS, zatimco u plen 
inicializovanyho systemu uz totez MFS namountujes bez problemu.

A tim jsme u hratek s NKPT.

Nevim jestli mas kernel prelozenej s tim, a pokud ano, tak jake cislo. N 
ejdriv bych to mozna zkusil bez toho. Pokud to nepouze, tak s tim, ale 
nedrzet se s hodnou prilis "pri zdi".

V "NOTES" pro AMD64 je uvedeno NKPT=31, coz se zda byt blbost - 
autotuningovy kod, ktery se pouzije, kdyz hodnotu nenadefinujes k tomu 
co "nejak odhadne" pricte 32 jako "rezervu pro jistotu". Takze pokud tam 
mas 31 z NOTES, nejsi ani na velikosti te rezervy.

Aktualni velikost nkpt prozrazuje read-only sysctl machdep.nkpt

Na stroji s 4GB to autotuning nastavi, hadam, tak na 40. Takze kdyz bude 
padat kernel prelozeny bez NPKT, zkusil byt to s nim, ale hodnotu tak 
nejmin 90.

> Konkretne dane nastane pri nasledujicich velikostech mfs rootu (velikost mfsrootu v B):
> 58 799 104 -> funguje, nabootuje ok
> 59 847 680 -> nefunguje, nenabootuje, nevyhodi kernel panic, ale po nacteni mfsrootu se proces bootovani sekne (posledni je vypis "tocitka" indikujici nacitani mfsrootu)
> 62 902 784 -> nefunguje, nenabootuje a vyhodi zmineny kernel panic

V prvnim pripade se "vsechno vejde". V druhem se samotny MFS se vejde, 
ale zbude tam uz jen malo volne pameti; "v ouzkejch" spatne zafunguje 
nejakej nedobre napsanej naslednej kod, kterej na nedostatek pameti 
nezareaguje dobre (nebo ho vubec nepozna a hrabne az za konec) a na tom 
to zvadne. No a posledni varianta je, ze uz se nevejde samotnej MFS ...

Jen hadam.

> Kernel samotny ma nejaky 13MB. Tzn. se vsim vsudy jsem pod 100MB.

Tak to je nkpt aspon 82. To jsme s tim odhadem 90 nebyl zas tak vedle a 
ja bych, nejmene v pocatecnich fazich pokusu, radeji hodnotu mirne 
prestrelil. Pak muzes zkusit couvat, kdyz ti tech par mega pameti bude lito.

> Drive jsem obcas na i386 bojoval s tim, ze jsem musel poladit NKPT, pokud byl mfsroot kolem 100MB (nebo vetsi).

Ja mam dojem, ze tech 32 bloku (64MB) rezervy uz se hodne dlouho 
nezvetsilo, ale naroky modulu a buhviceho jeste pomalinku rostou. Takze 
velikost MFS, kterou tam nactes bez poladeni hodnoty bude pomalu klesat. 
Mozna, ze 85MB uz je proste moc. A vysvetlovalo by to proc na 9-R jo a 
na 12-R ne.

Ale cele tohle je jen hypoteza - muze to byt zpusobene necim uplne jinym 
a pak samozrejme tuning nkpt nepomuze. Pro tenhle pripad muzu jen 
zopakovat moji oblibenou zasadu "verzim X.0 se vyhybejte" pripadne 
"nenasazujte release hned jak vyjde" - ty's udelal oboji ... ;-)

Dan

> On 24.1.2019 14:47, Mira Chlastak wrote:
>>   se peru s RELENG_12 a MFS_ROOT. Do ted dana masina jela na RELENG_9 a vse slapalo
> 
>> FreeBSD 12.0-RELEASE-p2 r343088 MOJE12-GENERIC amd64
>> FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1)
>> panic: pmap_growkernel: no memory to grow kernel


-- 
FreeBSD mailing list (users-l at freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l