Názory k článku Pro více než 4 GB RAM nepotřebujete 64 bitů - je tu PAE

Tohle je dost odvážné tvrzení (a jestli do toho skutečně pletete segmentaci, tak jste naprosto mimo). Můžete si sice vytvořit třeba 8GB (celkem) sdílené paměti, nebo paměťově mapovaných souborů atd., ale najednou je namapované mít nemůžete a znamená to brutální zásah do aplikace.

Bohužel mám jinou zkušenost. Provozujeme RH 5.2 a na něm Squid. Z důvodů neexistence 64 bitového Smartfilteru pak vše v 32bit. Oficiální stanovisko supportu je 4GB paměti na proces i z hlediska alokace. Pokud se mi povede nějak donutit squid k alokaci více paměti bude to výborné, ale proč by nás od toho odrazovali pokud by to šlo??

Je tam rozdiel.
to ze operacny system ma 64 GB RAM, je jedna vec, napr mozete spustit awk, ktore vyuzuje 4GB a potom napr. nieco v pythone, kde bude pouzitych dalsich 4GB, .....
Ale kazda aplikacia ma jednotlivo len 4GB. No samozrejme, stack, kod, mapovane subory, io, .... takze tak.

Pripajam link, inak autor vie celkom dobre prekladat, nabuduce by bolo dobre pripojit aj linku na zdroj, aby clovek mohol precitat original.

http://en.wikipedia.org/wiki/Physical_Address_Extension

na tej wikipedii, je to dobre rozpisane.

Budto jste intelektualni uchyl nebo e-mental. Jakmile zacnu neco prehazovat, neni problem jednim procesem vyuzit libovolne mnozstvi pameti. Limitem je jen pocet atomu ve vesmiru a to jeste kdovijestli.

Jeste jednou: jakmile zacnete neco prehazovat, mate podporu pro libovolne mnostvi pameti i na Atari 800. To, ze jste se upjal zrovna na jeden konkretni pripad prehazovani, je pouze vas problem.

Ehm, ak potrebujete napisat zmyslyplny program,je to problem, prepinanie segmentov sposobumje take vesele veci, ze v jendom segmente mate namapovany subor, 4GB bez 100KB, a kniznice, na spracovanie suboru ma 200KB, a pomocne datove struktury, maju 500 MB, a vsetko potrebujete, aby ste mohli spravit analyzu.
Ja osobne som nic take nerobil, ale bavil som sa s ludmi co pouzivali taketo mapovanie, ked frcal Turbo Pascal, a bolo to drsne.
Vyuzitie pre bezne aplikacie je problemove, su specialne oblasti, kde to ma zmysel, ale nie vo vseobecnosti.

[vzlyk] DOS/4GW, kde jsou ty casy ...

32bitova Fedora11 bude mit na 64bitovych procesorech 64bitovy kernel plus par veci, ktere kvuli tomu musi byt take 64bitove.

Na 32bitovem HW s prislusnou HW podporou bude instalovan automaticky PAE kernel.

Zde: https://fedoraproject.org/wiki/FeatureList - Supported Architectures

Kdysi jsme ve firmě měřili výkon PAE, 64bit, nePAE, atd... Ve většině přípádů se PAE téměř neprojevovalo, u některých aplikací to vypadalo i o něco rychlejší. Vždy se ale rozdíly pohybovaly do 1 procenta, takže to mohlo být způsobeno skoro čímkoliv (ikdyž jsme se snažili o stejné podmínky testu). Ve výkonu opravdu problém není.
Ovšem problém může nastat v tom, že u 32bit systému si kernel nemůže vzít všechnu pamět pro sebe, ve většině systémů je omezení 1GB. To znamená, že pokud máme souborový server s 8GB RAM, tak na 32bit systému se většinu času budeme dívat na 1GB cache a 7GB nevyužito...

ve většině systémů je omezení 1GB. To znamená, že pokud máme souborový server s 8GB RAM, tak na 32bit systému se většinu času budeme dívat na 1GB cache a 7GB nevyužito...

ne, page cache (nebo cokoli jiného v highmem) 3/1 splitem není ovlivněna

Nechci se přít, ale máme server, který exportuje disky přes iSCSI. Hodnota buffers nikdy nepřesáhla 1GB, přestože serverem proteče hodně dat... Je pravda, že server sám o sobě disky nemountuje, takže se jedná jen o block device cache, nikoliv souborovou cache.
Dělal jsem i nějaké drobné pokusy, kdy jsem na stroji se 4GB RAM dvakrát přečetl 3GB velký soubor. Na 64bit to při druhém čtení dělalo několik set MB/s, na 32bit výrazně méně. Do detailů jsem se ale nepouštěl, nebyl čas... Osobně nevidím potřebu používat 32bit systém, pokud nemám nějaký program, který to nepodporuje, což naštěstí většinou nemám :-) Ale to je jiná diskuse, nechtěl bych odbíhat od primárního tématu článku.

Driv to tak urcite bylo, protoze si pamatuju, ze jsem na to narazil (3-4 roky zpet) a ted byl jsem prekvapen, kdyz jsem si instaloval posledni pocitac (8GB RAM dualboot 32/64bit) a jak /dev/shm, tak cache vyuziva celou pamet.

To je skoro jako IPv6 s přídavným polem pro rozšíření Ip adresy. Prostě není co dodat.

to samé bylo kdysi u 16bitových procesorů (a některých dnešních mikrořadičů). přes sebe se mapovala 16bitová adresa a 16bitový offset posunutý o 4 bity. tehdy to ovšem bylo 2^(4+16) = 1MB :]

Mam 4gb ram a na desktope pouzivam ubuntu server jadro a mam pocit ze je to tak trochu lenivejsie. Vlastny kernel ale kompilovat nebudem...

nie som si celkom isty, ale nemoze to byt aj tym, ze serverove jadro ubuntu ma ine nastavenie schedulera?

Ja som nahodil na stroj s 4gb pameti 64bit kubuntu a subjektivne sa mi zda rychlejsie, najma praca s vacsimi objemami dat (napr otvorenie 100MB textaku v Kate a pod)...

ono toho nastaveni je vic a pri zatizeni je pak je znat ze odezva mizi

ono davat na desktop serverove jadro je skoro kontraproduktivni

Pokud ti jádro adresující RAM nad 4G připadá línější, tak to nejspíš není způsobeno PAE (jeho overhead je zanedbatelný), ale tím, že máš řadič disku, který neumí dělat DMA nad hranici 4G. Takže se pak při každém čtením nebo zápisu do horní paměti data kopírují mezi horní a dolní pamětí.

Řešením je použít řadič disku s 64-bitovým adresováním, např. AHCI, SIL3124 nebo lepší SCSI řadiče. Na IDE úplně zapomenout, IDE řadič s 64-bit adresováním snad není (aspoň o něm nevím).

Další možnost je použít IOMMU, to bude horní paměť přemapovávat do dolního adresního prostoru, tak, že ji 32-bitová PCI zařízení budou moct přímo použít. IOMMU mají pouze novější chipsety pro AMD. Je třeba zapnout GART v BIOSu a nastavit jeho velikost. Linux IOMMU umí použít pouze v 64-bitovém jádře (šlo by použít i v 32-bit módu, ale holt to do Linuxu pro 32-bit mód nikdo nenapsal).

U 64bit AMD procesoru dela IOMMU, stejne jako GART, primo samotny procesor (resp. radic pameti v procesoru).

Snad jsem to zle pochopil, ale nemluvíme o tom, že data jdou do HDD přes CPU, ale že řadič HDD si sám udělá DMA mezi pamětí a HDD. Tedy, CPU se to netýká a může dělat užitečné věci :-)

IOMMU je věc řadiče paměti, se kterým při zapnutém DMA komunikuje ten HDD. Ten řadič je v northbridge a ten je u procesorů s HyperTransportem (nové AMD procesory) součástí procesoru. Pro hardware je IOMMU transparentní stejně jako stránkování pro aplikace (protože je to stejná technologie).

ze by to bylo tim, ze desktop ma zapnutou preempci(lepsi odezvy) a server ji ma vypnutou(lepsi propustnost)? Pokud chces lepsi odezvy, pouzij desktop jadro...

Co to je a k cemu to je, prosim vas, ten licencni fajl?
(omlouvam se za neznalost, ale od roku 1994 nepouzivam windows)

Ha, ha, ha.
Pokud si prectete 'dokumentaci' k WinXP 32 prof, a podobne, zjisttite, ze WinXP sice PAE umi a zapinajiho ho (musi ho zapnout, aby mohli nastavit NX (No-Execute) bit pro 'ochranu' vykonavani stacku), ale protoze s tim drivery mely problemy (i kvuli DMA), viz M$ KB888137 tak se na pamet nepouziva, takze:

• mame HAL ktery umi a ma zapnute PAE
• ale nepouzivame ho na premapovani pameti, takze porad vidime pouze 4GB

(vlastne 3.2-3.5 GB, nebot ho nepouziva ani na premapovani MEM adress pro PCI/PCI-ex :-(

Tak tohle je fakt síla. WOW!

... ikdyz jsem skalni uzivatel Windows a skalni odpurce a nedobrovolny uzivatel Linuxu
chudinko:(
ale asi jsi i masochysta kdyz ctes o linuxu v 0:52:))))

Neni divu, ze vam to tak trva, kdyz mate problem s interpretaci vyznamu nekolikaradkovych tabulek :)

Sam si takovej a neschopnej k tomu :-).

PAE má teoretický limit 2 PiB (= 2 097 152 GiB), ale žádný současný procesor nepoužívá v PAE víc než 36 bitů (= neumí adresovat víc než 64 GiB), tak by mě zajímalo, jak to Microsoft dělá :)

Ta limitace na 4 GiB je u desktopovým Windows kvůli ovladačům. Takové PAE je používané jen proto, že to implementuje NX bit (ten bez PAE nefunguje).

M$ to nedela, pise ze to podporuje a z to po nich nekdo bude chtit, tak reknou, ze to musi taky podporovat CPU ;-)))
... proste mala lez, velka lez a MARKETING ;-))

Kdo vas vlastne nuti pouzivat Linux? Pokud je to zamestnavatel, tak ho zmente :-P Nebo to je uz takovy problem najit praci, ve ktere byste si mohl pouzivat jen svoje milovana Windows a nebyl omezen mrzkymi 64GB pameti v Linuxu? Pokud ano, tak je to dobra zprava pro Linux :-D

Take mam radost z toho, ze uz konecne nekteri zamestnavatele nuti pouzivat MS fans Linux.
My jsme si toho v "opacnem" smeru uzili dost, takze to potesi :-)

Reknete to uzivatelum Windows XP ;-))

V clanku uvedene kapacity se tykaji nejruznejsich serverovych edici MS Windows. Bezne 32bit windows (XP/Vista) zvladaji pouze 4GB (a to v praxi jeste ne cele) - cili to je takove pseudo PAE z rozhodnuti MS. A uzivatale technto systemu se musi spokojit s 3GB - to jim bude stacit na vsechno.

No a co? 640 KB musí stačit každému!!!

kecy.
použij kernel ntkr128g.exe +pae
viz google „readyfor4gb“
ReadyFor4GB, Memory Limit Patch For Windows. TCP-Z partner.
CompanyName : deepxw
FileDescription : Ready For 4GB Patch; TCP-Z partner.
FileVersion : 1.3.0.9
InternalName : ReadyFor4GB.exe
LegalCopyright : Copyright © 2008–2009 deepxw. All rights reserved.
OriginalFilename : ReadyFor4GB.exe
ProductName : Ready For 4GB Patch
ProductVersion : 1.3.0.9

Chytraky mam rad. Skoda jen, ze jsou vetsinou tak chytry, az jsou z toho uplne blbi.
Mimochodem, dnes mate skvelou prilezitost naemulovat na tech svych o deset let vyspelejsich procesorech smejd x86 tak, ze ve vysledku bude beh vseho nejmene 167,5 x rychlejsi. Tesim se na prvni dodavky, chytraku.

No prece aby neco tak super hyper vubec nekdo chtel. Jinak prece ti x86 zabednenci do smrti nepochopi rozdil mezi logickou a fyzickou adresaci pameti a spoustou dalsich veci. Jsme tupi, sesli na nas osviceni, o zarici!
BTW Dost mi pripominate marketing Apple. PowerPC je az 5x rychlejsi nez Intel, ale prechodem na Intel se vse az 5x zrychlilo.

Ta první věta byla hodně hloupá. Kdybyste řekl windowsovou komunitou (neboť widle na ničem jiným než x86 nikdy nepoběžijou), tak to dává smysl, pro Linux ne, ten funguje i na jiných platformách.
Na druhé straně sem nikdy nepochyboval, že x86 je bastl.

Nebyly nahodou uz kdysi davno Windows NT pro Alpha? Nebudou ted nahodou Windows 8 i pro ARM? Tak jakypak "ničem jiným než x86 nikdy nepoběžijou"...

Na linuxu je 64bitu vyreseno od portu na DEC Alpha (muj DS-20 ma podle datasheetu stejne velky bandwidth do RAM, jako Athlon do L2 :-)), takze s portem na 64bit nebyl az takovy problem, jaky byt mohl. Dulezite je, ze jsou vychytane hnusne chyby, kde nekdo ocekava hodnotu pevne velikosti a podobne ...

S takovou aplikací se ovšem běžný uživatel v praxi nikdy nesetká. To mi pripomnelo jeden slavny Gatesuv vyrok :-) Podle me si bude i sam autor tak za 5 let klepat na celo jak mohl takovou totalni kravinu napsat.

Desktopove Windows sice PAE podporuji ale vice jak 4GB pameti z politickych duvodu pouzit nepovoli (v praxi je to jeste zmenseno o diry v adresnim prostoru, ktere v nem nadelal BIOS). Bylo by fajn, kdyby aspon tento blud byl v clanku opraven aby to lidi nematlo.

32bit proces nemuze namapovat pro svou potrebu 4GB - pamet jadra. V linuxu se nejcasteji pouziva 3/1 split takze pro proces zustava 3GB. Ve Windows je implicitne dokonce 2G/2G

Dale by se dalo polemizovat o bezproblemovosti PAE pod Linuxem. Sam Linus nekolikrat napsal, ze to je nutne zlo a neco ve smyslu "pokud mas 16GB pameti a neobtezujes se upgradovat na 64bit tak nechtej po me aby me obtezovaly tvoje problemy". Jeden z ceskych vyvojaru jadra Pavel Machek se o highmem vyjadroval take velice privetive ve smyslu "doufam, ze highmem chcipne drive, nez budeme muset ty bugy vyresit"

"32bit proces nemuze namapovat pro svou potrebu 4GB - pamet jadra. V linuxu se nejcasteji pouziva 3/1 split takze pro proces zustava 3GB. Ve Windows je implicitne dokonce 2G/2G"

Existoval i patch na 4G/4G split pro Linux --- t.j. proces dostane plné 4G virtuálního adresního a jádro taky. Ale zpomalovalo to, protože se pak při každém vstupu do jádra přepínala tabulka stránek. Na ten patch se již zapomnělo, protože ten 1G navíc za to zpomelaní nikomu nestál.

Tak tak, vsichni vyvojari linuxu vedi, ze je to zverstvo a nikdy to uz opravovat nebudou.

Vida, to staví tvrzení z článku -- "Nás bude ale určitě nejvíce zajímat Linux, který je na PAE připraven výborně a jeho podpora tohoto rozšíření je nejlepší z výše uvedených systémů" -- do trochu jiného světla :)

"Obecně tedy platí, že pokud váš procesor běží na více než 500 MHz, obsahuje také podporu PAE."

Neplatí, já mám AMD K6-3+ na 600 (přetaktovaný 550) a PAE nemá.

Porucha osobnosti nema nahodou skratku PAE ?

Nemá, má zkratku PD (nebo česky PO). Schizoidní pak SPD.

Nn, PAE je Prenathal Alcohol Exposure

A prenathal je co? Nějaký novotvar od prenatal?

Jelikož se jedná o hardwarovou funkci, je překlad adres přímý a nevyžaduje stránkové tabulky.

Ehm, PAE přidává ještě jednu vrstvu stránkových tabulek (Page-Directory Pointer Table se čtyřmi záznamy), protože rozšířením mapování ze 32bitů na 64bitů se do těch původních tabulek dá nacpat jen čtvrtina stránek, což dokáže mapovat jen 4 KiB × 512 × 512 = 1 GiB pro každou aplikaci. Mimochodem všechny stránkové tabulky stejně interpretuje procesor.

Doska zvladne 8GB, ale nie som Radek Hulan, aby som na desktope bezal nejaky Oracle + webserver :-)

heh. na mojem deskopu mi bezi vse ;) .. na router s verejnou ip forwarduju akorat porty

No moje deska umí 2×4 GiB, bohužel tak velké moduly se ještě nedělají (NTB DDR3), takže jedu 2×2 GiB :/. Na serveru mám 4×2 GiB a deska zvládne 4×4 GiB (když jsem to kupoval, tak se nedělaly dost velké moduly, a zatím se mi nechce kupovat nové paměti, když stojí >10 kKč a stejně 80 % té současné zabírá cache). Oboje samozřejmě 64bit kernel.

Doska mi zozere 8G v 4 slotoch, zabite mam zatial len 2 (2x2GB) a asi to v blizkej dobe zarvem cele. Striham video divym sposobom (premiere + avisynth naraz) a popri tom sa to este bezne pouziva a prakticky to nevypinam (S3 sleep, ktory zerie asi 13W a Vypnout skonci tak na 12.5W :) na zamyslenie...) a teda po tyzdni v beznom stave mam 1G RAM in use len malickostami typu firefox, posta, nejaky ten total commander, word, messenger a zopar toolov.
Aby sa mi wokna chovali aspon trocha ako operacny system a nesvietil mi disk pri kazdom ALT+TAB, vysvetlil som mu, ze pagefile nie je spravna cesta ako rozsirit RAM (pri beznom pouzivani aj gejmovani odporucam kazdemu so 4GB aj na 32bite), kedze Mrkwosoftacka swap politika odhodi na disk cokolvek, co sedi aspon 3 minuty minimalizovane na liste, lebo sak bude tu RAM urcite za chvilku treba... Teraz mi to nediskotekuje ani ked sa prepnem z Falloutu 3, lebo treba nieco kuknut ne nete...
Pri mojom zamerani sa bohuzial od Widiel asi tak skoro nepohnem, lebo sa Adobe... Na druhom kompe uz je Ubuntu a kedze ako odreagovanie mi staci Dune 2000 a Counter Strike, co tam v Crossoveri ide ako hodinky, tak dalsie Widly uz nepotrebujem ;) (Este musim otestovat Heroes4... este ze si clovek spomenie. Wine rulezz!!!)

sestavu (tj. základní desku + procesor), kam jde narvat víc, než 4GB RAM a přitom procesor není 64bit :o

32bitové aplikace (user space) běží bez problémů i pod 64bitovým kernelem (navíc rychleji, protože 64bit kernel je rychlejší), na to není potřeba mít PAE.

".... S takovou aplikací se ovšem běžný uživatel v praxi nikdy nesetká."

Započítejte i paměť na grafickém akcelerátoru a uvažujte o moderních počítačových hrách. Ze 4GB virtuálního prostoru, který má aplikace k dispozici, je 1GB ukousnut rozdělením 3/1 mezi jádro a uživ. prostor. Dalších x MB se použije na namapování paměti grafické karty - dnes běžně 0.5-1GB. No a hned vám zbývají "pouhé" 2GB adresního prostoru, kam se musí vejít všechny knihovny a data, a to už některým hrám nebo CADům bude pomalu těsno.

Nevím jestli Linux běžně mapuje grafickou paměť do prostoru aplikace, ale pravděpodobně by to mohly dělat některé proprietární ovladače na grafiku. Kvůli tomuto problému mě jeden čas padal Zaklínač, páč windowsy mají 2/2 split a pokud má grafická karta 0.5GB ram a directx ovladače si ji namapovaly do prostoru dokonce vícekrát, tak už skutečně moc místa nezbylo.

No ale windowsy jsou problém sám o sobě, tam si klidně nechám 32b, na ty hry to stačí a víc se s tím nechci obtěžovat. V Linuxu mi 64b šlape v pohodě skoro rok a nejsou s tím žádný problémy. Souhlasím s Linusem a spol., že PAE je jen ubohá berlička z dob před 64b a snad by se o něm ani nemělo ve slušné společnosti mluvit ;-)

Podle mne by jedinym duvodem pro instalovani 32bit Linuxu na 64bit stroj mohl byt leda proprietarni binarni ovladac k nejakemu obstaroznimu hardwaru, u ktereho neexistuje 64bit verze. Jinak mne nenapada zadny jiny duvod - veskere linuxove aplikace jsou budto uz davno i v 64bitech, pripadne chodi bez problemu v 32bit rezimu (z tech vyznamnejsich mne napada snad jen Skype), par desitek MB 32bit knihoven neni v dobe mnohasetgigabytovych disku snad zadny problem.

A ten klient s 32bit emulaci nefunguje? (A Skype jsem dal jen jako priklad proprietarni aplikace, ke ktere neni ani 64bit verze, ani jakakoliv alternativa).

Například citrix neni v 64 bitove verzi.

Mam upresnujici dotaz, jede vsechno pod 64bit?
Rekneme, ze pouzivam ruzne starsi kody, veci, co nejsou
v repozitarich. Budu mit problemy se 64bity?

Nebo jakmile bezi system pod 64bity, je vsechno v pohode?

A bezi-li 64bitovy system - je v pohode poustet tam 32bitove veci?

V extremu, muzu mit zaklad 64bitovy a
pouzivat vsechny 32bitove aplikace z repozitaru?

diky

> Mam upresnujici dotaz, jede vsechno pod 64bit?
Mam plne 64bit system a vsetko, co potrebujem, funguje. Stretol som sa zatial len s 32bit DB2, ktora nechodila, ale myslim ze uz je 64bit verzia.

> A bezi-li 64bitovy system - je v pohode poustet tam 32bitove veci?
Ano. Napriklad flash plugin je 32bitovy a bezi v 64bit firefoxe. Bohuzial, pomerne nestabilne.

> V extremu, muzu mit zaklad 64bitovy a pouzivat vsechny 32bitove aplikace z repozitaru?
Neskusal som, ale rozmyslam nad 32bitovou javou, lebo 64bitova je katastrofa.

celkem v pohodne neni. websphere neumi nektere veci pokud bezi pod 64-bitovou JVM.

Zbytečně to komplikujete, 32-bitové aplikace můžete na 64-bitových systémech spouštět i bez chroot jail. Potřebujete jen dva různé adresáře se sdílenými knihovnami. Řada distribucí tak funguje out-of-the-box.

Pocitace s 32 bitovym processorom nedokazu vyuzit 4GB RAM ... je to nepotrebna kravina

mam k tomu dotaz,celou dobu ziji v tom ze 32bit x86 v chranetem rezimu umi adresovat tusim 64TB pameti, 4GB je jen limit jednoho segmentu. ruzne OS s 4GB limitem jsou jen produktem nekoncepcnosti a "lenosti" tvurcu,ze nevyuzivaji naplno virtualizaci/segmentaci pameti. uznavam,kolem problematiky pmode a adresace jsem nikdy nic nedelal,takze vychazim jen z literatury,takze...jak to teda je? nejde mi to nejak pres nos.4 GB jsem do ted videl jako limit vel;okosti segmentu,takze pri dobre udelanem OS je to limit na souvisle alokovane pole v jednom kuse....

diky za vysvetleni

Žádný 32-bitový operační systém nepoužívá poitnery se segmentací. Kdybys chtěl použít segmentaci, tak bys musel pointer rozšířit z 32 na 48 bitů. Nahrávání toho segmentového registru je pomalé (6 - 20 tiků na různých procesorech), takže kdybys použil segmentaci na přístup k obyčejným datům, tak bys každý přístup do paměti zpomalil o tento počet tiků.

Pokud se segmentace používá, tak jen v případech, kdy není třeba ty segmentové registry pořád přepínat, např. na thread-local-storage (v userspace) nebo CPU-local-storage (v kernelu).

dik,takze je to jak jsem myslel, "lenost" pri pouzivani flat modelu a jenom near jmp+call

btw ktery OS vyuziva tedy segmentaci? je nejaky vubec?

Pouze 16-bitové prostředí používají segmentaci. Tam by to bez segmentace nešlo, bez segmentace by člověk měl max 64kB dat.

16-bitové kompilátory mají možnost zvolit model (tiny, small, medium, compact, large, huge), který určuje, jak moc je program velký --- zda tam mají být 16-bitové pointery nebo 32-bitové pointery segment:offset na funkce a na data. Ve větším modelu může být větší velikost programu nebo dat, ale zase to běží pomaleji kvůli tomu, že se s každým přístupem do paměti nahrávají ty segmentové registry.

s tim uplne tak nesouhlasim.z aplikacniho hlediska,i kdyby mel jeden proces code=data=stack rozhodne by mel kazdy 4gb jen pro sebe.navic int far *ptr v nekterych rozsirenich C jeste na 16bitech bylo,nebyl by problem s tim delat na 32bitech.me se proste nelibi,ze se vubex nevyuziva velka cast toho co architerkura nabizi, na x86 HDT/LDT tabulky+ 4 urovne opravneni (pokud si to pamatuju dobre) jsou dobre hw prostredky pro navrzeni schopneho bezpecneho OS

Z tech serioznich 32b asi zadny.

Ono si tim totiz clovek az tak moc nepomuze, protoze segmenty se stejne nakonec mapuji do 32bitove linearni adresy.

Asi by se dalo predstavit, ze operacni system vyrobi vice deskriptoru nez se do adresniho prostoru vejde s tim ze jenom nektere budou present a pak bude odchytavat Segment Fault (intelovina, nesouvisi se SEGV) pri mov cosi,%ds a v tabulce stranek nejaky odpovidajici kus stranek prohodi aby ukazovaly na jine fyzicke adresy a deskriptor zpristupni. Nicmene nema to moc smysl, protoze aplikace ktera potrebuje hory pameti muze vicemene totez delat v userspace (v linuxu vyrabenim souboru v /dev/shm a mmapem, windows na to dokonce maji jakesi funkce primo pro to urcene). Pokud by to delal OS celou situaci jeste komplikuje to, ze by na to nekdo musel napsat kompilator, ktery s tim pocita.

Teoreticky by sa nemuseli az tak casto prehadzovat. Kod moze byt vo vlastnom segmente 4GB (CS), zasobnik SS, na najcastejsie data DS, a na ostatne niekolko 4GB segmentov (ES,FS,GS), splu teda 16 GB data + 4GB stack, keby sa vyuzivala segmentacia. Je ale pravda ze by sa to horsie programovalo, chcelo by to nejako logicky rozdelit data do segmentov tak, aby nebolo treba vsade pouzivat segmentove pointre. ( 4 heapy)

To by pak už nešlo programovat v C. V C může tentýž pointer ukazovat na read-only data, na read-write data, na zásobník nebo na haldu (nebo i na funkci ... ale ten nemůžeš dereferencovat, pouze volat). A když bys ten pointer dereferencoval, tak bys musel rozhodnout, kam ten pointer patří a podle toho použít segmentový registr.

Buď bys to testoval automaticky ve vygenerovaném kódu --- to by ti zpomalovalo každé hrábnutí do paměti přes pointer.

Nebo bys musel programátora nutit, aby ke každému pointeru určoval, do jakého segmentu patří --- a pak by ti na tom obyčejné C programy nechodily.

Třeba by to šlo programovat ve starém Fortranu (nemá pointery vůbec) nebo v původním Wirthově Pascalu (má pointery, ale nejde tam pointerem ukazovat na jiné proměnné nebo pole, pouze na haldu; ukazování pointerem na proměnné tam přidal snad až Borland v jejich Turbo Pascalu).

Třeba OS/2 v kernel módu má odlišnou bázi SS a DS segmentu. Má to blbý důsledek, nejde tam napsat něco jako void f() { int X; int *P = &X; ... } --- protože do P se uloží adresa vůči SS segmentu, ale v momentě, kdy se to dereferencuje, tak se použije segment DS --- takže v momentě, kdy se odkaz na zásobník v kódu vyskytne, musí se ten kód ručně upravovat a musí se k tomu uměle přičítat rozdíl DS a SS bází.

Čtyřmi segmentovými registry DS,ES,FS,GS vlastně stejně současně nenaadresuješ 16GB. Každý z nich má totiž pouze 32-bitovou bázi a délku. Jediná možnost, jak byses přes těch 4GB dostal, by bylo, že bys opravdu musel při každém přístupu do paměti nahrát segmentový register a při výpadku segmentu jiný segment odmapovat, abys pro nový segment udělal místo v tom 4G rozsahu.

Zacnem od konca. No je uz moc hodin a nestudoval som PAE, neslo by tie segmenty vyriesit cez PAE?
A tiez len som si matne spomenul ze nieco sa so segmentami riesi aj v C cez pragmy. Idem uz spat, tak len nadhodim priklad #pragma data_seg(".my_data1")
... ze by spravit si takto segmenty a dat tam napr. velke staticke polia. Jeden pointer co by mohol obsahovat adresu hociktoreho segmentu by sa nedal spravit, ale to v podstate ani nemusi byt potrebne pri aplikaciach co si vedia rozne typy dat rozdelit do segmentov.

Více segmentů v C lze použít, akorát ten pointer musí být typu long long (64 bitů) a nést tak s sebou i informaci o segmentu. V jednom pokusném OS, jenž jsem spoluvyvíjel, jsme to tak měli, ale segmentaci jsme používali pro její původní účel, tzn. rozdělení přístupových práv k paměti, ne pro mapování více než 4 GiB.

Segmentace se nepouziva, vsichni jedou flat memory model. x86-64 puvodni intelskou segmentaci nepodporuje vubec.

Segmentace je sice 46bitová, ale mapuje se na 32bitovou logickou adresu, která se stránkuje (a ta přes PAE může mít až 51 bitů). Ta 32bitová logická adresa, která je společná pro všechny segmenty, je to omezení na 4 GiB. Šlo by to sice řešit zneplatněním segmentů a přehazováním logické adresace při přístupu k takovému segmentu, ale to by bylo dost pomalé.

Krom toho by se stejně muselo používat PAE, protože jinak se ta logická adresa mapuje na 32bitovou fyzickou adresu.

Mam 4GB pamate, CPU s podporou PAE kernel s HIGMENM=y a free stale ukazuje len cca 3GB. Bios ukaze 4. Kde by mohol byt problem?

Zapnout v BIOSu "remap memory hole" nebo podobnou volbu, pokud to ta deska umí. Pokud to deska neumí, pak smůla, víc jak 3GB z toho nepůjde dostat.

Rozbehal jste nekdo ATI binary video driver (fglrx) v Linuxu s PAE? Me proste vytuhne pri startx.
Taky si myslim ze tohle je presne duvod proc Ubuntu odmita zaclenit PAE-desktop-kernel do distribuce, maji myslim jenom server-kernel s podporou PAE.
Taky by me zajimalo, zda Nvidia binary driver podporuje PAE.

Co si spominam, tak sem v praci na stroji s i5 a 8GB zkousel v Debianu zkompilovat PAE kernel a videlo to pak tech 8GB a Xka s oficialnim NVidia driverem (GT230) taky fungovaly normalne. Nic krom prohozeni kernelu sem nenastavoval.