ACPI, memory management a inicializace OS (chobotnicovity problem)

Roman Divacky rdivacky at freebsd.org
Fri Jan 4 18:06:23 CET 2008


On Fri, Jan 04, 2008 at 10:29:46AM +0100, Dan Lukes wrote:
> 
> 	Zacalo to tim, ze se mi nedari FreeBSD 6.3-PRE (ani jiny) na mem 
> pocitaci spolehlive uspavat a budit. Pak jsem si vsimnul hlasky uppne na 
> zacatku bootu:
> 
> acpi_alloc_wakeup_handler: can't alloc wake memory
> 
> 
> Takze jsem zacal hledat - v tom miste se ACPI snazi sehnat stranku 
> paneti, do ktere presune "vstavaci" kod. Tato stranka musi byt na 
> adresach 0-0x9FFFF tak, aby byla k dispozici uz v okamziku spousteni 
> jeste v realnem modu.
> 
> Ale ve chvili, kdy se ACPI kod dostane "k lizu" uz jsou uplne vsechny 
> mozne stranky rozsahu 0-9FFFFh (fyzicke pameti) obsazeny.
> 
> Jednotlive komponenty jadra i loadovatelne moduly registruji sve 
> inicializacni rutiny s urcitou prioritou. Memory management, ktery 
> vytvori seznam volnych stranek startuje s prioritou 
> SI_SUB_VM/SI_ORDER_FIRST, rutina ACPI, ktera se pameti domaha a uz ji 
> nedostane s prioritou SI_SUB_KMEM/SI_ORDER_ANY
> 
> Ty priority jsou pomerne tesne za sebou, takze by clovek cekal, ze se 
> budou spoustet kratce po sobe - mezi nimi je uz jen alokace kernelove 
> pameti s prioritu SI_SUB_KMEM/SI_ORDER_FIRST
> 
> Zahajil jsem tedy tim, ze jsem si acpi posunul na uroven 
> SI_SUB_VM/SI_ORDER_SECOND abych predbehl tu kernelovou alokaci a tedy 
> mezi globalni inicializaci pameti a pozadavkem na jeji pouziti ze strany 
> ACPI nebylo nic. Nepomohlo - pamet vycerpana. Dalsim ladenim se ukazalo, 
> ze stale plati, ze pamet sezere kernelova alokace = kmeminit().


co presne v tom kmeminit() "zere" pamet? ja tam vidim akorat ze to vytvori
mapu pro kernel a pak vytvori nejake uma zony. to by nemelo zabrat prilis
pameti..


> Nojo - jenze, pote co jsem v ACPI posunul prioritu by se kmeminit mel 
> dostat k lizu az po ACPI - ale on to nevi a klidne se dal spousti pred.
> 
> Po delsi dobe ladeni se ukazalo, ze s prioritama spousteni je to trochu 
> slozitejsi. Na zacatku jsou "v baliku" spoustenych rutin, ktery se 
> setridi dle priorit a pak se z nej vybira, jen interne zakompilovane 
> komponenty.
> 
> 	Terve kdyz se dojde k linker_preload() na urovni 
> SI_SUB_KLD/SI_ORDER_MIDDLE (to uz je pomerne dost pozde) se do baliku 
> pridaji inicializacni rutiny preloadovanych kernelovych modulu (a seznam 
> se znovu setridi). Tim se nejprve ted dostanou "k lizu" (zdanlive) 
> prioritnejsi inicializacni rutiny modulu (staticke uz jsou davno 
> hotove). Na prioritnejsich urovnich jsou tedy v tomto okamziku jen 
> modulove inicializacni rutiny (staticke uz jsou davno hotove). Teprve ve 
> chvili kdy znovu dojdeme na uroven SI_SUB_KLD/SI_ORDER_MIDDLE se zacnou 
> staticke a preloadovane rutiny stridat, tentorat opravdu ciste podle 
> hodnoty priority.
> 
> To znamena, ze si s prioritou acpi_alloc_wakeup_handler() muzu hejbat 
> jak chci - stejne se mi brzo nespusti (alespon dokud bude ACPI 
> loadovatelny modul - a to bude, protoze zakompilovat ho nelze).

ta analyza vypada dobre
 
> Takze konecne nejaka otazka - je tu nekdo, kdo ma nastudovano jak v 
> jadre FreeBSD funguje memory management na urovni rozhrani fyzicke a 
> virtualni pameti ? Zakladni teoreticke otazky - tedy jak funguje 
> strankovani a podobne - s tim problem nemam. Smeruju k tomu, aby se 
> kernel soustredil na fyzickou pamet na vyssich adresach, kterych je 
> dost, a pokud mozno, dokud to jde, ponechaval volne fyzicke stranky s 
> nizkymi adresami, protoze ty jsou cenny neobnovitelny zdroj.
> 
> A druhak - ma nekdo nastudovan dobre dynamicky jadrovy linker, konkretne 
> jeho vztah k linker-setum (to by vyhledove umoznilo zaradit modulovou 
> inicializaci spravne podle priorit mezi incializaci statickych komponent).

jsem si pomerne jisty ze nikdo kdo cte tuhle konferenci tyhle znalosti nema :)

napis to na hackers@ nebo nekam...

mne jen napada zkusit posunout zacatek te kernel mapy, treba nad 1MB nebo tak.
to definuje VM_MIN_KERNEL_ADDRESS

ale fakt tohel se na tehle konferenci asi (resp. urcite) nevyresi

roman



More information about the Users-l mailing list