NEXT 5/2008 - Ponad czwartym
gigabajtem

raport: bariera 4 GB pamięci fizycznej w 32-bitowych
systemach
Data: 22 kwietnia 2008
Pamięć RAM, zwłaszcza typu DDR2, jest obecnie bardzo

tania. Nic dziwnego, że coraz więcej komputerów wyposażanych jest
np. w dwa 2-gigabajtowe moduły. Radość z posiadania takiej ilości
RAM-u często szybko mija, gdy się okazuje, że system operacyjny
zamiast czterech gigabajtów melduje mniej więcej trzy.

Zdaniem redaktora

Krzysztof Roszak
redaktor działów Software i Internet

Nieco z przekąsem mogę stwierdzić, że problem czterech gigabajtów mnie nie
dotyczy. Powód jest prosty – odkąd mam 64-bitowy procesor, używam tylko
takich systemów; głównie Kubuntu, choć w odwodzie jest jeszcze XP x64. I
chociaż rozwiązania do 32-bitowych platform Microsoftu przeznaczonych do
użytku domowego na razie nie widać, bo zostało ono sztucznie stłamszone
przez producenta, uważam, że to właśnie analiza pochodzenia problemów z 36-
bitowym adresowaniem pozwala zrozumieć, jak często decyzje podjęte w trybie
„na teraz nam wystarczy” mszczą się ze zdwojoną siłą w przyszłości. W tym
kontekście dziwi mnie małpi upór dostawców zestawów OEM, którzy sprzedają
nowe pecety z 32-bitową edycją Visty w trosce o dobro klienta. Przecież 64-
bitowe systemy mogą wciąż sprawiać kłopoty w grach. Ciekawa podejście. Ja
mogę tylko zapewnić, że mój komputer problemów z działaniem
podzespołównie ma ani w 64-bitowym XP, ani Linuksie.

Taki scenariusz, mimo że dość często ostatnio spotykany, wciąż dla wielu
użytkowników jest zaskoczeniem. Na licznych forach dyskusyjnych pojawiają się
pytania, gdzie znika niemal (a czasem i ponad) gigabajt. Chociaż w większości
przypadków odpowiedzi adresują poprawnie źródło problemu – osiągnięcie
granicy 32-bitowego adresowania, fakty często mieszają się z mitami.
Można zatem przeczytać m.in. o tym, że jest to wina Windows XP, a problem
rozwiązuje instalacja Visty; że 32-bitowe systemy nie widzą więcej niż 4
gigabajty pamięci; a także znaleźć rewolucyjne rozwiązania problemu, np.
przez dezaktywację pliku wymiany (ang. swap space) w systemie operacyjnym.
Takie odpowiedzi biorą się oczywiście z niezrozumienia bardzo
skomplikowanego zagadnienia, jakim jest obsługa pamięci w komputerze, a
także z nieznajomości kilku faktów z historii informatyki. Warto przyjrzeć się
sprawie dokładniej: z czego wynika bariera 4 GB, czy i jak można ją obejść,
wreszcie – czy obsługa RAM-u to jedyny problem w tej kwestii.

Pamięć pamięci nierówna

Często używanym w dyskusjach zwrotem jest: system nie widzi pamięci. Jest
ono ambiwalentne pod co najmniej dwoma względami. Pierwszy, co to znaczy,
że system widzi pamięć – czy stanowi to tylko kwestię oprogramowania, czy
może to sprzęt dyktuje systemom warunki pracy oraz czy widzenie jest
tożsame z wykorzystywaniem? Drugi zaś, czym właściwie w tym kontekście jest
pamięć?
Odpowiedź należy zacząć od wyraźnego wypunktowania, że rodzajów pamięci
w systemach operacyjnych jest kilka. Zacznijmy od tego, co oczywiste – RAM-u,
czyli pamięci fizycznej instalowanej na płytach głównych. Jej uzupełnieniem jest
pamięć (lub plik) wymiany – wydzielony obszar dysku twardego pełniący rolę
rozszerzenia RAM-u, w kategorii ilościowej. Obie pamięci razem wzięte tworzą
obszar, w ramach którego system operacyjny i aplikacje mogą umieszczać
potrzebne dane.
Pamięć wirtualna procesu

Każdy proces dysponuje własnym wirtualnym obszarem adresacji, a system
operacyjny dokonuje mapowania tych adresów na konkretne fragmenty
pamięci fizycznej.
Oczywistym jest, że miejsce przechowywania zapisywanych w nim informacji
musi być jednoznacznie określone, tak aby system wiedział, do której komórki
pamięci czy sektora dysku twardego sięgnąć w celu jej odczytu. Problem ten
rozwiązuje użycie mechanizmu adresowania. Obszar całkowitej dostępnej
pamięci jest dzielony na numerowane bloki, z których każdy ma własny adres.

32-bitowe adresowanie

Jest on oczywiście liczbą całkowitą z zakresu od zera do maksymalnej wartości,
jaką może obsłużyć procesor. Ta zaś zależy wprost od liczby bitów używanych
przez CPU do adresacji. Łatwo policzyć, że dla 32-bitowej jednostki jest to 232,
co daje 4 G unikatowych adresów. Wszystko byłoby proste, gdybyśmy przyjęli
założenie, że jedyną dostępną pamięcią jest RAM – i tylko jej dotyczy adresacja.
Ponieważ tak nie jest, systemy operacyjne od dawna dysponują mechanizmami
pozwalającymi obejść ten limit.

Te 4 miliardy adresów stanowią więc tzw. pamięć wirtualną, widoczną dla
aplikacji. System operacyjny stosuje zaś algorytm mapujący każdy adres
wirtualny z tego zakresu na fizyczny. Tym drugim może być zarówno komórka
RAM-u, jak i sektor dysku objęty plikiem wymiany. Jak łatwo się przekonać,
swap file w 32-bitowych systemach może być większy niż 4 GB. Nie można
zatem zastosować np. dwóch osobnych wirtualnych przestrzeni adresowych,
osobno dla RAM-u i swapa, bo w przypadku tej drugiej pamięci fizycznej
również nie dałoby się użyć mapowania jeden do jednego. Trzeba użyć metody
pośredniej.

Memory Hole Remapping, czyli

łatanie pamięci

Funkcja Memory Hole Remapping
działa na poziomie układów płyty
głównej, w pełni niskopoziomowo.
Polega ona na zwracaniu systemom
operacyjnym przestrzeni adresowej
ponad czwartym gigabajtem w

ilości tożsamej z zajętą przestrzenią adresową na potrzeby obsługi urządzeń
poniżej tej granicy.
Aplikacje w 32-bitowym środowisku do alokacji pamięci używają określonej
procedury systemowej, zwracającej adres wirtualny. Tak działa np. metoda
malloc() w języku C, przekazująca programowi 32-bitowy wskaźnik typu
unsigned int. Szkopuł w tym, że z tej samej procedury korzystają wszystkie
programy i biblioteki, włącznie z jądrem systemu.
Dodatkowo twórcy systemów operacyjnych dość długo borykali się z kwestią
zapewnienia kompatybilności (i tym samym działania) programów
oczekujących otrzymania od systemu np. jednomegabajtowego bloku pamięci o
ciągłej przestrzeni adresowej (np. od 0x0h do 0x100000h). Jako że takich
programów w systemie uruchomić można kilka, logicznym krokiem było
przyjęcie, iż każdy z nich otrzyma swoją własną, ciągłą, wirtualną przestrzeń
adresową (ang. Virtual Address Space).
W ten sposób program wciąż widzi ciągły obszar pamięci, a jądro systemu

zajmie się mapowaniem adresów z każdej z VAS na fizyczne adresy (patrz
ilustracja „Pamięć wirtualna procesu”). Takie rozwiązanie funkcjonuje obecnie
we wszystkich popularnych systemach operacyjnych, w tym Windows i
Linuksie.

Halo, tu sprzęt…

Jakby tych problemów było mało, dochodziły kolejne – tym razem sprzętowe.
Każde urządzenie obecne w zestawie PC musi się przecież komunikować z CPU i
pamięcią za pośrednictwem układów płyty głównej (chipsetu). To oczywiste,
zwłaszcza w przypadku komponentów z własną pamięcią – jak karta graficzna.
Dostęp do tego typu urządzeń musi być zagwarantowany dla 32-bitowego CPU,
niezależnie od systemu operacyjnego, niskopoziomowo. Oznacza to zaś tyle, iż
można operować jedynie na adresach fizycznych.
Przyjęto więc rozwiązanie, że chipsety płyt głównych mapują pamięć
komponentów na adresy fizyczne „od góry”, czyli od adresu 0xFFFFFFFF w dół –
tyle, ile jest wymagane. Zajęty w ten sposób zakres adresów fizycznych staje
się jednocześnie niedostępny dla pamięci RAM, a co więcej, system operacyjny
musi przewidywać możliwość bezpośredniego odwołania się do tego zakresu
adresów (tzw. tryb DMA – Direct Memory Mapping). W latach gdy mechanizm
ten opracowywano (koniec ubiegłego wieku), standardem w pecetach było 64–
128 MB RAM-u, więc takie założenie było całkiem sensowne, zwłaszcza że
samej przestrzeni adresowej mniej więcej taka ilość wystarczała na obsługę
ówczesnego sprzętu. Ostatecznie 3,9 GB zamiast pełnych czterech to jeszcze
nie problem.
Obecnie sprawa ma się zgoła inaczej. Sama karta graficzna zabiera
standardowo od 256 MB do nierzadko 1 GB, a w kolejce po adres na wyłączność
są kolejne urządzenia: magistrala PCI/PCIe, kontrolery USB/FireWire czy
RAID/SATA itd. Warto jednak zapamiętać, że konkretna liczba z puli fizycznych
adresów, o jaką uszczuplą one system, zależy tylko i wyłącznie od płyty głównej
i zamontowanych komponentów, nigdy od systemu. Stąd w jednych
konfiguracjach 4 GB RAM-u meldowane jest np. 3,5 GB, zaś w innych tylko 2,75
GB.

Oddać, co zabrane

Już pod koniec ubiegłego milenium producenci płyt głównych i procesorów
dostrzegli nadchodzący problem znikającej pamięci – ówcześnie głównie w
serwerach, w których zawsze każdy megabajt jest cenny. Rozwiązanie
zaproponował Intel, wchodząc na rynek z procesorem Pentium Pro w 1997 r.
Dysponował on tzw. trybem PAE (Physical Address Extension), czyli metodą
poszerzającą zakres adresacji fizycznej. Rzecz jasna, jedyną metodą
osiągnięcia tego jest zwiększenie liczby bitów w adresie – dodano ich całe

cztery. Wynikowe 36 bitów daje możliwość obsłużenia 64 GB RAM-u. Takie
rozszerzenie oferują także wszystkie nowsze CPU Intela oraz jednostki AMD, od
Ath- lona K7 wzwyż.
Oczywiście, aby móc powstałą nadwyżkę wykorzystać, konieczne jest wsparcie
ze strony układów płyty głównej. Znowu jednak kwestie kompatybilności dały o
sobie znać. Większość ówczesnych systemów i sterowników urządzeń pisanych
było z założeniem, że do komunikacji międzysprzętowej przeznaczony będzie
adres mniejszy od 0xFFFFFFFF.
Zdecydowano więc, że tak pozostanie, zaś chipsety płyt głównych będą
zwracać tak zajęty zakres adresów ponad czwartym gigabajtem. Patrząc na
rozmieszczenie danych w pamięci fizycznej, powstała w ten sposób dziura
poniżej 4 GB, a technika jej łatania dostała nazwę Memory Hole Remapping.
Jest ona wspierana praktycznie przez wszystkie nowoczesne płyty główne. W
przypadku niektórych modeli można ją wyłączyć, co zawsze wiąże się z
zawężeniem dostępnej ilości RAM-u w systemach operacyjnych, także 64-
bitowych.
Jak wielki jest rozmiar tej dziury w pamięci oraz czy jest ona zwracana, można
sprawdzić, choćby uruchamiając narzędzie memtest86 z płyty startowej 32-
bitowego Ubuntu. Testuje ono osobno dostępny obszar poniżej 4 gigabajta i
zwróconą przestrzeń ponad tą granicą. Jeśli w polu Address Range w trakcie
testów ten drugi zakres nie będzie wyświetlany, funkcja Memory Hole
Remapping jest niedostępna lub wyłączona w BIOS-ie.

Jak wymusić tryb PAE?

Systemy Windows automatycznie stosują tryb PAE, o ile wykryte zostaną co
najmniej 4 gigabajty RAM-u. W pozostałych przypadkach można go wymusić,
aby np. przekonać się, jaki ma to wpływ na wydajność komputera. Jeśli
używana wersja systemu to 2000/XP/2003, wystarczy użyć przełącznika /PAE na
końcu wpisu startowego w pliku boot.ini.

W systemach Vista/Server 2008 należy zaś wydać komendę
bcdedit /set pae forceenable w wierszu polecenia. Systemy
Linux obsługujące pakiety binarne, np. Debian, Ubuntu czy
Fedora, pozwalają na równie prostą podmianę jądra. W
przypadku Ubuntu wystarczy zainstalować w menedżerze pakietów pakiet
linux-image-2.6.XX-server oraz towarzyszący mu pakiet modułów, czyli linux-
ubuntu-modules-2.6.XX-server, oraz w razie potrzeby wszelkie wymagane przez
system zależności (np. sterowniki własnościowe, linux-restricted-modules-XX-
server).

W Fedorze zaś odpowiednie pakiety jądra i modułów są oznaczane
przyrostkiem -PAE. W bieżącej, ósmej wersji Fedory
zainstalować należy paczki kernel-PAE- -2.6.XX.fc8 oraz
wszelkie używane sterowniki, zwłaszcza te z repozytorium
rpm.livna.org, np. kmod-fglrx-PAE czy kmod-madwifi-PAE.
Alternatywną metodą w każdym systemie Linux jest ręczna
kompilacja jądra. W trakcie konfiguracji, np. poleceniem

make xconfig, należy jedynie pamiętać o przejściu do sekcji Processor type and
features i ustawieniu opcji High memory support na 64 GB.

Od 32 do 36 bitów

Jest jednak jasne, że taki sposób traktowania adresu fizycznego musiał być
poprawnie zaimplementowany w jądrach systemów, by mogły one tak
odzyskaną pamięć wykorzystywać. Nie jest to sprawa trywialna, zwłaszcza że
wymaga zmiany sposobu, w jaki dokonywana jest translacja adresu wirtualnego
na fizyczny. Z punktu widzenia aplikacji nie miałoby żadnego znaczenia – wciąż
maksymalna przestrzeń adresowa dla pojedynczego procesu wynosi bowiem 4
GB, gdyby nie to, że mechanizm PAE może wiązać się ze spadkiem wydajności
całego podsystemu obsługującego pamięć.
Czemu tak się dzieje? Otóż tak samo jak dostęp do powierzchni dysku twardego
nie jest możliwy z dokładnością do jednego bitu, a jedynie przez sektory (na
warstwie fizycznej) i klastry (grupy sektorów w stosowanym systemie plików),
w podobny sposób dokonywana jest adresacja pamięci. Proces nie może
alokować bezpośrednio np. wybranych 5 sąsiednich bajtów, bo pamięć
podzielona jest na tzw. strony, domyślnie o rozmiarze 4 kB. Jądra systemów
operacyjnych grupują strony w tablice, a tablice w katalogi. Taki trójstopniowy
mechanizm adresacji komórek fizycznej pamięci nazywany jest
stronicowaniem.
Aktywacja mechanizmu PAE (formalnie przez ustawienie piątego bitu w
rejestrze CR4 procesora – CR4.PAE=1) zmienia interpretację adresu. O tym, w
jaki sposób, zależy od tego, czy wykorzystywane są wciąż 4 kB strony, czy też
ustawieniem flagi PS w katalogu stron (PDE.PS=1) ich rozmiar zwiększa się do 2
MB.

W pierwszym przypadku do obsługi większej ilości pamięci dokładana jest
kolejna, czwarta warstwa adresacji, tzw. wskaźniki na katalogi stron. Oprócz
tego same katalogi i tablice stron stają się formalnie 64-bitowe, choć
używanych jest ledwie 36 bitów. Pomijając fakt, że wydłuża to proces dotarcia
do konkretnej komórki RAM-u, jest jeszcze jedna wada: zwiększenie liczby
indeksów potrzebnych do zapisania, które strony są w danym momencie zajęte
przez aplikacje. Drugi sposób jest znacznie wydajniejszy, bo pozostawia
trójwarstwowe stronicowanie, zmienia jedynie rozmiar używanych struktur
danych.
Od czasu procesorów Pentium II dostępna jest także technologia PSE – Page
Size Extension, nazywana często również PSE-36. Polega ona na pracy z
pojedynczymi stronami o rozmiarze 4 MB zamiast 4 kB, a efekt działania jest
analogiczny do PAE w drugim z opisanych trybów.

Władza w rękach systemu

O ile większość opisywanych dotąd rozwiązań była niezależna od systemów
operacyjnych, tak na tym etapie sprawa się wyraźnie skomplikowała.
Pierwszym OS-em wspierającym PAE/PSE był Windows 2000, także w wersji
Professional, obecnie obsługują je wszystkie 32-bitowe systemy firmy Microsoft.
W przypadku wykrycia przez nie 4 GB (lub więcej) RAM-u, tryb PAE jest
uaktywniany domyślnie. Można też wymusić jego stosowanie przy mniejszych
ilościach pamięci (patrz: ramka „Jak wymusić tryb PAE?”).
Dlaczego zatem najpopularniejszy obecnie XP SP2 nie radzi sobie z dużą ilością
pamięci? Odpowiedź jest bardzo prosta: bo sztucznie ograniczono w nim
obsługę fizycznej pamięci do 4 GB. Oficjalny powód takiego ograniczenia to
zachowanie jak najwyższej niezawodności systemu. Pierwsze wersje, do Service
Packa SP1a włącznie, mogły rozpoznać i wykorzystać pełne 4 GB. Jak się jednak
okazało, mnóstwo urządzeń, głównie tych drobnych, takich jak przeżywające
dopiero gwałtowny wzrost popularności w latach 2001–2004 klucze USB
wszelkiej postaci, ma niedopracowane sterowniki lub kontrolery sprzętowe. Pęd
do możliwie najszybszego wprowadzenia produktu na rynek powodował często,
że programiści uciekali się do daleko idących uproszczeń.
Głównym grzechem było założenie, że system do obsługi DMA zwróci
sterownikowi i nada urządzeniu adres 32-bitowy, co niekoniecznie faktycznie
miało miejsce. W takiej sytuacji objawem było wyświetlenie przez Windows
niechlubnego niebieskiego ekranu. Aby zabezpieczyć się przed taką
ewentualnością, zablokowano w systemie możliwość odwoływania się do
adresów ponad czwartym gigabajtem. W Windows XP zmianę tę wprowadzono
w dodatku SP2, analogicznie zachowują się wszystkie 32-bitowe wersje Visty.
Zagranie iście genialne – z jednej strony zabezpieczenie się przed potencjalną
falą telefonów do pomocy technicznej powodowaną błędami niezależnymi do
Microsoftu, a z drugiej – otwarcie możliwości różnicowania wersji serwerowych
systemów także pod względem adresowalnej pamięci RAM. I tak np. Server
2003 w wersji podstawowej także używa tylko 4 GB, więcej jest w stanie
zaadresować dopiero od wersji Enterprise.

Stronicowanie pamięci w 36-
bitowym trybie PAE

Włączenie trybu PAE umożliwia co prawda wykorzystanie maksymalnie 64 GB
pamięci fizycznej, ale nie za darmo. Kosztem jest rozbudowanie schematu
wskazywania komórek pamięci o jeden poziom (tablicę wskaźników katalogu
stron) w stosunku do klasycznego, 32-bitowego stronicowania.
Pingwiny na ratunek
W tym miejscu należy wyraźnie wspomnieć, że nawet systemy z włączonym i
działającym PAE, ale sztucznym ograniczeniem, jak XP SP1, nie mogą poradzić
sobie z ilością większą niż 4 GB. Innymi słowy, jeżeli w komputerze z takim
systemem jest np. 6 GB RAM-u, zaprezentowane zostanie dokładnie 4 GB i ani
bajtu ponadto.
A co z systemami Linux czy BSD? Oba doskonale radzą sobie z 36-bitowym
rozszerzeniem. Jądro rodziny BSD obsługuje flagę PAE od wersji 4.9 (2005 r.), w
Linuksie jej obsługa została wprowadzona od jądra serii 2.6 (2003 r.). Z tym że
większość obecnych dystrybucji 32-bitowych również dystrybuowanych jest z
kernelem pozbawionym tej możliwości.
W odróżnieniu od Windows jednak da się ją dość łatwo włączyć – wystarczy
użyć prekompilowanego jądra lub skompilować własne, włączając opcję obsługi
pamięci wysokiej (high memory) do 64 GB. Jądra 2.6 mogą pracować bowiem w
trzech trybach: podstawowym (obsługiwany jest jedynie 1 GB pamięci),
rozszerzonym do 4 GB (domyślny w większości dystrybucji, analogiczny do
trybu bez PAE w XP SP2) lub do właśnie 64 GB. Wiąże się to bezpośrednio z
tym, jak jądro Linuksa dzieli dostępną pulę adresów wirtualnych na segmenty.
Przełącznika takiego, z oczywistego powodu – braku potrzeby jego istnienia, nie
ma w 64-bitowym kernelu.

W jądrze pamięci

Wnikliwi użytkownicy Linuksa zauważą zapewne, że system ten nigdy nie
raportuje użytkownikom pełnej ilości RAM-u jako dostępnej pamięci fizycznej;
niezależnie od (nie)użycia jądra PAE. Brakuje zwykle około 150–250 MB. Co jest
powodem? W górnym obszarze poniżej pierwszego gigabajta 128 MB zajętych
jest przez struktury kernela, a pamięć ta nie jest dostępna ani widoczna dla
procesów użytkownika.

A pozostałe kilkadziesiąt megabajtów? Wystarczy uruchomić komendę top lub
free -m, aby się przekonać, że zajmują ją kolejne bufory systemowe,
przechowujące m.in. wskaźniki na używane bloki pamięci. Nie ma zatem
powodów do obaw – pamięć ta, choć nie jest dostępna dla użytkownika, jest w
pełni wykorzystywana przez system.
Znacznie ważniejsze jest co innego: ilość wirtualnej pamięci dostępnej dla
pojedynczego procesu. Jak wspomnieliśmy na początku artykułu, maksymalnie
są to 4 GB. To, ile będzie to w rzeczywistości, zależy właśnie od sposobu, w jaki
jądro rozdziela adresy na dostępne tylko dla procesów jądra i dla tych
działających w przestrzeni użytkownika. Pierwszy obszar to pamięć
współdzielona dla wszystkich aplikacji, więc żadna z nich nie może jej mieć na
wyłączność, w takim trybie dostępny jest tylko pozostały obszar adresacji
wirtualnej.
W systemach Windows przyjęty jest podział 1:1, co oznacza, że z 4 GB każda
aplikacja może korzystać tylko z dwóch gigabajtów. I to jest prawdziwy problem
dla większości aplikacji zarówno stricte konsumenckich, np. nowoczesne gry,
jak i biznesowych, np. bazy danych. Microsoft pozwala jednak na swobodną
manipulację podziałem, lecz tylko w ograniczonym obszarze. Przełącznikiem /
3GB w pliku boot.ini można wymusić w systemach 2000, 2003 i XP alokowanie
trzech gigabajtów wirtualnego adresu dla trybu użytkownika. Aby podobny
efekt uzyskać w Viście, należy wydać polecenie bcdedit /set increaseUserVa
3072.
Dokładny tuning ilości pamięci dostępnej do aplikacji w Viście można
przeprowadzić, zmieniając podaną wartość na inną, z zakresu 2048–3072. Do
Windows 2000/XP/2003 analogicznie zadziała kombinacja przełączników /3GB /
userva=XXXX, gdzie XXXX to liczba megabajtów z tego samego zakresu.
Dlaczego istnieje taka możliwość? W teorii może się bowiem zdarzyć, że
ograniczenie pamięci jądra do 1 GB spowoduje np. niemożność załadowania się
wszystkich niezbędnych sterowników – kart graficznych w szczególności.
Linux ma podobne problemy, ale domyślnie przyjętym rozwiązaniem jest
właśnie podział w stosunku 3:1, odpowiadający funkcjonalnie przełącznikowi /
3GB w Windows XP. W takim reżimie pracują np. jądra ze standardowej
kompilacji Ubuntu. Można, rzecz jasna, zmienić stan rzeczy, ale z reguły
wymaga to samodzielnej rekompilacji kernela, poza tym oprócz wspomnianego
3:1 do wyboru są jeszcze tylko dwa predefiniowane tryby – 2:2 (tożsamy z
domyślnym w Windows) oraz 1:3.

Gra warta świeczki?

Z powyższego, dość powierzchownego przedstawienia genezy i rozwiązań
problemu, można wciąż mieć wątpliwości, czy walka o 36 bitów ma sens.
Odpowiedź brzmi: tak. Przeprowadzone przez nas testy pokazały, że
aktywowanie tego trybu nie ma praktycznie wpływu na ogólną wydajność
systemu, zarówno Windows XP, jak i Linuksa. W przypadku drugiego z
systemów włączenie obsługi 64 GB RAM-u jest jak najbardziej wskazane.
Z Windows sprawa ma się o tyle gorzej, że nie da się podmienić jądra systemu.
Wprawdzie XP ma dwa pliki kernela: ntkrnlos.exe oraz ntkrnlpa.exe, gdzie to
drugie zawiera obsługę PAE. Można wymusić jego ładowanie przełącznikiem

/kernel=ntkrnlpa.exe, ale efekty takiej zmiany w praktyce będą niezauważalne.
Pewnym rozwiązaniem jest powrót do Service Packa 1a, który umożliwi
wykorzystanie pełnych czterech gigabajtów, ale rozwiązanie to ma tę wadę, że
w tej wersji system gorzej współpracuje z wielordzeniowymi procesorami, co
przekłada się na ogólnie gorszą wydajność aplikacji. Zakup i instalacja systemu
Windows 2003 Enterprise jest zaś oczywiście skutecznym rozwiązaniem, ale
dalece zbyt kosztownym, aby polecić go domowym użytkownikom.
Jedynym faktycznie skutecznym rozwiązaniem w świecie Windows jest migracja
do 64--bitowych wersji XP lub Visty. Niestety, XP x64 trudno znaleźć w sklepach
nawet w wersji pudełkowej, zaś Vistę większość dostawców OEM oferuje
preinstalowaną jedynie w 32-bitowej edycji. Wymagającym użytkownikom 32-
bitowych platform Microsoft nie daje obecnie sensownej alternatywy.

http://www.nextmag.pl/index.php/artykul/aid/66/pid/8