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@freebsd.cz)
http://www.freebsd.cz/listserv/listinfo/users-l
