Omezení velikosti paměti počítače, OS a procesu

25.4.2008 19:42 | Přečteno: 4443×

Kolem omezení velikosti paměti, kterou je schopen adresovat procesor a čipová sada, kolik z toho je k dispozici v operačním systému a kolik paměti může používat proces panuje značný chaos. Nejlépe to je vidět na, periodicky opakujících se, otázkách typu "mám v počítači 4 GiB paměti a systém vidí jen 3,5 GiB" a bohužel i v odpovědích na tyto otázky.

Fyzický a virtuální adresní prostor a adresy

Fyzická adresa by se dala přirovnat k poštovní adrese- určuje konkrétní buňku fyzické paměti. Za běhu systému bude táž fyzická adresa ukazovat vždy na stejnou buňku*. Fyzický adresní prostor je pak rozsahem fyzických adres, které lze použít. Je důležité vědět, že ve fyzickém adresním prostoru můžou být díry a/nebo místa vyhrazená pro mapování paměti hardware. Pokud je instalováno méně fyzické paměti než je fyzický adresní prostor pak logicky některé fyzické adresy ukazují do prázdna.

Virtuální adresní prostor si lze představit jako pestrobarevnou koláž. Na některých místech jsou díry, jinde jsou různě rozesety přilepené stránky fyzického adresního prostoru. Některé obsahují kód jiná data. Jinde jsou nalepené poznámky "Kdyby se tuto stránku někdo snažil přečíst tak na toto místo načti tento úsek tohoto souboru."{1} nebo "Kdyby se na tuto stránku někdo snažil zapsat tak najdi volnou stránku fyzické paměti a přilep ji sem"{2}. Každá stránka má navíc "semafor" určující, zda se na dané místo smí zapisovat, číst či provádět kód. Teď si představte, že virtuálních prostorů je ve stejné chvíli spoustu (zjednodušeně řečeno- kolik procesů tolik virtuálních prostorů) a že jednotlivé stránky fyzické paměti můžou být přilepeny v žádné nebo také v mnoha nebo dokonce všech virtuálních prostorech. Hodnota semaforu stejné fyzické stránky může být v různých virtuálních prostorech různá.

Odbočka stranou- jak funguje správa paměti

Když už jsem si to tak hezky zadefinoval s tou koláží, tak nemůžu odolat abych do celého obrazu nepřidal ještě lapidární popis fungování správy paměti VP nového procesu vznikne jako kopie VP rodičovského procesu přičemž na všechny stránky, kde je namapována paměť se přilepí nálepka "Kdyby se sem někdo pokusil zapsat tak tuto fyzickou stránku zkopíruj, kopii přilep na toto místo a zápis proveď do této kopie."{3}. Toto je velice užitečný mechanizmus přezdívaný COW neboli Copy on Write. Umožní procesům sdílet stránky fyzické paměť až do doby, dokud se nezmění. Co proces tedy konkrétně ve svém prostoru má? Je to závislé na operačním systému ale základ je podobný. Chtě nechtě tam je jádro včetně jeho datových struktur. Dále knihovny, které program využívá (semafor povolí provádění ale ne zápis protože stejnou knihovnu může sdílet více procesů), soubory mapované do paměti, kód samotného procesu a konečně paměť, kterou si proces naalokoval. Když si proces vyžádá od operačního systému paměť, tak správce paměti najde volný rozsah VIRTUÁLNÍCH stránek a dá na ně nálepky {2}. Takové paměti se říká comitted. Při samotné alokaci tedy vůbec nedochází k využití fyzické paměti. K tomu dojde až když si proces na přidělenou paměť "šáhne". Lze tedy napsat aplikaci, která vyčerpá veškerý VIRTUÁLNÍ adresní prostor procesu i když bude spousta volné fyzické paměti k dispozici. Mnohem častěji ale vzniká opačný problém- všechny procesy dohromady využijí celou volnou zásobu FYZICKÉ paměti. Správce paměti v takové situaci vybere fyzické stránky, které nebyly dlouho použity, začne je odtrhávat z VP procesů, zapisovat na disk a lepit místo nich nálepky {1}. <joke>Počítač se zpomalí a uživatel restartuje Firefox a vše se vrátí do normálu</joke>. Izolace procesů a jádra a sdílených knihoven je realizována pomocí semaforů. Izolace procesů mezi sebou je realizována jednoduše tím, že ve virtuálním prostoru jednoho procesu nejsou namapovány fyzické stránky jiného procesu tudíž k žádné interakci nemůže dojít. Pokud aplikace šáhne na místo virtuální paměti, kde je díra nebo kde to nedovolí semafor tak program havaruje se známou hláškou Segmentation fault v Linuxu nebo s hláškou, která vzbuzuje mezi běžnými uživateli Windows neskutečné asociace (paměť na adrese XYZ nelze přečíst/zapsat, nebo něco v tomto smyslu).

Omezení fyzického adresního prostoru procesoru

Už zde je schovaný první (řádně zakořeněný) mýtus: n-bitový procesor dokáže (prý z definice tohoto pojmu) přímo adresovat 2^n bajtů paměti. To je prosím nesmysl. Neplatilo to v době 8bit procesorů (které vesměs adresovaly 2^16 bajtů) a neplatí to ani dnes. Na x86 platformě procesory adresují 2^36 bajtů a na x86_64 mají současné procesory strop 2^48 (AMD) nebo 2^40 (Intel).

Omezení fyzického adresního prostoru řadiče paměti

Řadiče paměti (Intel- součást severního můstku chipsetu, AMD- součást procesoru) většinou dále omezují fyzický adresní prostor někdy z technologických, někdy z marketingových důvodů. U Intelu to je v případě aktuálních desktopových chipsetů 8 GiB neboli 33 bity. Serverové chipsety umožní osadit až 64 GiB.

Omezení fyzického adresního prostoru operačního systému

Tady se začínají komplikace. A také jeden mýtus, který se šíří jako mor: 32bit operační systém může využít maximálně 4 GiB (nebo 3,něco GiB podle varianty mýtu) paměti. Tento mýtus má tak tuhý kořínek jelikož přesně tak se chovají desktopové varianty Windows. Je zajímavé sledovat, jak politické rozhodnutí nějaké firmy má vliv na všeobecné povědomí. V principu má 32bit OS na x86 platformě přístup díky PAE (v linuxu se často vídá pojem HIGHMEM) přístup k celé šířce fyz. adresního prostoru procesoru tedy 36  itů. Přináší to ale různá úskalí a komplikace. Například klasická 32bit PCI umí adresovat jen spodních 32 bitů a odtud plyne nutnost použití tzv. bounce bufferů - jedno dodatečné kopírování dat v paměti navíc. Všechny ovladače s tím musí samozřejmě počítat. Občas se říká, že samotné PAE přináší navíc i výkonnostní réžii, ta je ale v praxi na moderních procesorech minimální. Je třeba si uvědomit, že paměťový model x86_64 je v podstatě nástavbou PAE. Windows XP a Vista používají PAE na počítačích s NX bitem implicitně nezávisle na množství paměti. O 64bit operačních systémech nemá cenu se moc bavit- tam kde rozhoduje marketing umělá omezení jsou (Vista Home Basic - 8 GiB, Premium 16 GiB), tam kde nerozhoduje tam se omezení kryji s možnostmi řadiče paměti.

BIOS má rád ementál

Bios rezervuje určitou část fyzického adresního prostoru pro zařízení, a kvůli tomu udělá díru ve fyzické paměti. Množství ukousnuté paměti paradoxně nezávisí ani tak na připojeném hardware ale opravdu čistě na BIOSu základní desky. Pohádky o tom, že rozhoduje velikost paměti grafické karty... jsou prostě jen pohádkami. Slušný BIOS pak fyzickou paměť přemapuje výše. Pokud máte 4 GiB paměti a BIOS z ní kus sebere a přemapuje nad 4 GiB. Zde se uplatní omezení operačního systému. Běžné 32bit varianty Windows a Linux bez HIGHMEM>4 GiB paměť nad 4 GiB nejsou schopny adresovat tudíž hlásí velikost paměti 4 GiB - velikost_díry. V tom spočívá celá záhada "ztracené paměti".

Omezení virtuálního adresního prostoru procesoru

Tady není moc nad čím dumat. Na x86 je adresa veliká 32bitů a to je omezení velikosti virtuální paměti. Jaký smysl má větší fyzický prostor než virtuální? Smysl je v tom, že několik procesu se svými virtuálními adresními prostory může pokrýt celý fyzický prostor. Na x86_64 platformě je z technických důvodů v současných implementacích horní hranicí 48 bitů přestože adresy jsou 64bitové.

Omezení virtuálního adresního prostoru procesu

Řadič paměti ani BIOS nemají do virtuálního prostoru co kecat, takže jdeme rovnou k OS potažmo k procesům. Je zde schovaný poslední mýtus, o kterém dnes napíšu: já žádné aplikace, které potřebují více než 4 GiB paměti nepotřebuju takže mi stačí 32bit OS. Už dříve jsme si ukázali, že do virtuálního prostoru procesu se mapuje daleko více věcí než jen samotná data procesu. V praxi nejčastěji je situace taková, že na x86 má proces k dispozici 2 GiB - sdílené knihovny - soubory mapované do paměti - kód aplikace. A to už tak dobře nevypadá. Proč je na začátku 2 GiB a ne 4? Protože celý virtuální prostor se děli na část vyhrazenou pro jádro a číst pro proces. Implicitní poměr ve Windows je 2GiB:2GiB což má své výhody- podle nejvyššího bitu se pozná kam adresa šahá ale dá se změnit na 3GiB pro aplikaci a 1 GiB pro proces. V Linuxu jsou možnosti nastavení poměru širší (pomocí patchů jádra) dokonce je možné i 4GiB/4GiB ale stále platí, že 2GiB:2GiB je přirozeným a nejméně problémovým poměrem.

*) V případě poštovní adresy nemusí ležet podobná čísla popisná blízko sebe. Stejně tomu je i u fyzické adresy v počítači. O tom, kde (na kterém paměťovém modulu nebo dokonce čipu) konkrétně leží daná fyzická adresa rozhoduje řadič paměti (translace není mnohdy tak triviální jak by se mohlo na první pohled zdát třeba v případe použití interleavingu nebo při dual channel složenyým z modulů různé velikosti nebo při promíchání single sided a double sided modulů).

       

Komentáře

[progdan]

Skvely zapisek, moc diky. Vzdycky me zajimalo jak to asi tak +- s tou pameti je, ale moje prirozena lenost mi znemoznovala si to vyhledat.

[Mr.Gentleman]

Díky za povedený článek. Už jsem myslel, že ani nebloguješ, protože pěkně dlouho se mi v RSS od tebe nic neukázalo, ale dnešek mě vyvedl z omylu. Jen tak dál.

[michich]

V Linuxu na i386 je přirozené rozdělení paměťového prostoru 3GB/1GB. Cokoli jiného je porušení ABI (ale to často nemusí vadit). 4GB/4GB patch dělal myslím Ingo Molnar, ale dneska už to asi nikdo neudržuje. Znamenalo to příliš velké zpomalení syscallů a hlavně už to dneska nikdo nepotřebuje, když máme x86_64.

[Rezza]

A nemelo by 640 KB stacit? ;)

[Dizie]

:D n1 vtipek

[miho]

Na jednom fileserveru jsem viděl v praxi nasazený dokonce 1GiB/3GiB.

[stativ]

Tleskám, nejlepší věc na ábíčku od doby tvých zápisků porovnávajících Linux a Vistu. Pokud bys to někdy někde chtěl vydat jako článek, byl bych nadšen.

[Rezza]

Ne fakt moc pekne blogove zapisky oproti nekterym vykrikum. Osobne na hodnotne blogy chodim na Root, ale tady se zase rad pobavim. A byvaji tu moc pekne cestovatelske blogy, kdyz ajtaci vyrazi do sveta za lepsim :)

[Ondrej 'SanTiago' Zajicek]

Slušný BIOS pak fyzickou paměť přemapuje výše. Pokud máte 4 GiB paměti a BIOS z ní kus sebere a přemapuje nad 4 GiB

A pokud to neudela, tak to nemusi byt nutne problem BIOSu, ale treba limitace chipsetu (radice pameti). Alespon u nekterych Intelich chipsetu se tento problem uvadi.

[Kvakor]

U AMD tohle nastesit dela radic pameti v procesoru pres IOMMU. Ta take umoznuje pridat jeste jedno mapovani pameti, a to pamet z pohledu zarizeni. Diky ni nemusi byt napr. DMA buffery spojite, i kdyz zarizeni neumi scatter/gather, navic pamet muze byt fyzicky nad hranici 4GB i pro zariceni, co zvladaji jen 32bit adresy. Je pravda, ze tohle sice umelo uz GART u AGP, ale jen pro grafiky a jen do 4GB.

[YYY]

Mozna, ze by nebylo spatne tento zapisek vydat jako clanek. Je opravdu prinosny. Diky za nej.. :)

[tsLnox]

+1, díky za perfektní vysvětlení :)

[Pihhan]

Děkuji za výborný článek. Sice nikde nenarážím na jakékoliv limity, protože 4G paměti si nemůžu dovolit, ani pro ně nemám využití, ale až to budu potřebovat, budu to vědět :)

Ale chci se zeptat, zda víte, čím je v linuxu omezená paměť do 1GB. Přidali jsme nové moduly do serveru (malý server, je tam přesně 1GB), ale systém je jaksi neumí obsluhovat celé a na komplet 1GB nedosáhne. Přitom při adresování po bajtech jsem na hony vzálený od limitu adresové sběrnice a i když je tam docela dost zařízení, pochybuju že by pro ně bios naalokoval přes 3GB. Nemůžu se podívat do logu, server už běží dlouho a log z bootu se odroloval pryč. Ale psalo to tam něco ve smyslu nutnosti podpory vysoké paměti. Tu jsem do svého 2.6.15.6 kernelu záměrně nedával, protože 4G ta deska snad ani neumí dát do slotů a určitě nebylo v plánu takovou hromadu paměti koupit.

Zajímalo by mě tedy, jestli víte, co je za limit na 1GB a proč se na to něco muselo zapnout, když virtuální i fyzická paměť musí stačit i bez speciálního algoritmu.

[miho]

Předpokládám, že jádro vidí 896 MiB. To zase souvisí se zónami paměti v Linuxu. Doporučeným řešením je... oželet těch 128MiB :) Pokud se vám to nelíbí tak zapnout nejnižší variantu HIGHMEMu. Nemám se teď možnost podívat protože mi uname -a momentálně vrací Darwin xxxs-macbook.local 9.2.2 Darwin Kernel Version 9.2.2: Tue Mar 4 21:17:34 PST 2008; root:xnu-1228.4.31~1/RELEASE_I386 i386 ale myslím že je označena v configu jako HIGHMEM 2GB.

Tohle jsem do zápisku nedával protože mi to přišlo, že tohle se řešilo tak před pěti léty...