Hery's devlog

Organizacja przestrzeni adresowej procesu jest jedną z istotniejszych decyzji projektowych, która może zaważyć na wydajności całego systemu. W praktyce okazuje się, że dla każdej architektury istnieje jedno najpopularniejsze i najczęściej także najlepsze rozwiązanie. Warto jednak przyjrzeć się jakie ciekawe mechanizmy oferują platformy mniej znane (choć nie zawsze rzadziej spotykane) niż x86.

IA-32 (aka x86)

W tej architekturze procesor udostępnia dwa mechanizmy zarządzania i ochrony pamięci. Są to segmentacja oraz stronicowanie. Pierwszy z nich jest niejako pozostałością po procesorach 16 bitowych i trybie rzeczywistym. Dodatkowo w trybie IA-32e segmentacja jest wspierana jedynie w ograniczonym zakresie. Wszystko to powoduje, że współczesne systemy operacyjne praktycznie nie korzystają z tego mechanizmu stosując model pamięci zwany protected flat model. Polega on na utworzeniu jedynie czterech segmentów (segmenty kodu i danych dla jądra i przestrzeni użytkownika), a ochrona pamięci jest realizowana przez stronicowanie.

Zdecydowana większość jąder systemów operacyjnych organizuje przestrzeń adresową procesów w ten sam sposób, najlepszy dla tej architektury. Polega to na umieszczeniu stron należących do programu w dolnej części przestrzeni adresowej a stron jądra w górnej części przestrzeni adresowej. Z tym że strony jądra są ustawione globalnie, a więc są takie same dla wszystkich procesów. Głównym powodem dla którego jądro jest zwykle umieszczone w wyższych adresach pamięci jest tryb emulacji 8086 (v86). Wymusza on aby kod działający w tym trybie znajdował się w pierwszym megabajcie pamięci. Gdyby kernel umieszczony w dolnych adresach pamięci, chciał udostępnić ten tryb programom, wprowadziłoby to dodatkowe komplikacje.

Dzięki takiemu rozwiązaniu kopiowanie danych z pamięci programu do pamięci jądra jest proste i wydajne. Także, przy okazji wywołań systemowych nie zachodzi potrzeba zmiany katalogu stron. Niestosowanie rozbudowanego systemu segmentacji pozwala ominąć problemy związane z innymi adresami tego samego obiektu w różnych kontekstach wykonania.

Najistotniejszą wadą jest ograniczenie ilości pamięci dostępnej dla jednego procesu. W zależności od systemu operacyjnego i jego konfiguracji są to 2GB lub 3GB w przypadku systemów 32 bitowych (oczywiście PAE nie ma wpływu na te wartości). Problem ten obecnie nie istnieje w przypadku systemów 64 bitowych, gdzie maksymalny rozmiar przestrzeni adresowej jest nieporównywalnie większy od ilości pamięci operacyjnej zainstalowanej w większości komputerów.

sun4u (aka UltraSPARC, SPARCv9)

Zupełnie inne rozwiązanie zastosował Sun Microsystems w swojej architekturze sun4u. Wprowadzono w niej mechanizm nazwany address space identifiers (ASI). Pozwala on na umieszczenie jądra w osobnej przestrzeni adresowej. Na tej platformie sprzętowej adres komórki pamięci składa się dodatkowo z ośmiobitowego ASI, który określa do której przestrzeni adresowej odnosi się dany adres. Dzięki temu kernel może kopiować dane między różnymi przestrzeniami adresowymi nie zmieniając tej głównej w której się znajduje oraz bez potrzeby aktualizacji rekordów w TLB.

Rozwiązanie zastosowane w sun4u pozwala na udostępnienie programom maksymalnego rozmiaru przestrzeni adresowej, zachowując przy tym prostotę i wydajność operacji kopiowania danych między pamięcią użytkownika a pamięcią jądra. Dodatkowo znika problem niewielkiej przestrzeni adresowej dostępnej kernelowi.

Warto także zauważyć, że powyższe rozwiązanie jest możliwe do implementacji na platformie x86. Pojawia się wtedy jednak problem mało wydajnego kopiowania danych miedzy kernelem a programami. Próba implementacji takiego sposobu organizacji przestrzeni adresowej wymagałaby ustawienia każdego przerwania wywołującego funkcje kernela jako task gate. Dzięki temu każdy przerwanie skutkowałoby zmianą przestrzeni adresowej i uruchomieniem kodu kernela. Następnie jądro mogłoby uzyskać dostęp do przestrzeni adresowych innych procesów odpowiednio mapując strony pamięci. Rozwiązanie to jednak wiąże się z dużą dodatkowych operacji i częstymi potrzebami aktualizacji TLB. Z tego powodu jest to właściwie tylko ciekawostka.

MIPS

Pewne różnice w stosunku do x86 można także zaobserwować w architekturze MIPS. Pamięć wirtualna jest podzielona na cztery segmenty z czego tylko jeden, o rozmiarze 2 GB jest dostępny dla programów. Pozostałe trzy segmenty są do użytku jądra.

• Pierwszy z nich kseg0 jest stale zmapowany na pierwsze 512 MB pamięci fizycznej (w związku z czym nie ma potrzeby wykorzystywania TLB) i procesor stosuje co do niego pamięć cache. W tym segmencie znajdują się procedury obsługi przerwań (o ile system nie jest jeszcze w fazie ładowania). Warto zauważyć, że architektura MIPS wymaga od kernela obsłużenia każdego TLB miss.
• Kolejny segment kseg1 tak samo jak poprzedni jest zmapowany na pierwsze 512 MB pamięci fizycznej. Jedyną istotną różnicą jest fakt, że procesor nie wykorzystuje w nim pamięci podręcznej. Dzięki temu po uruchomieniu CPU może bezpiecznie rozpocząć wykonywanie kodu zawartego w tym segmencie, bez ryzyka wystąpienia błędu spowodowanego niezdefiniowaną wartością w cache. Tak długo jak długo jest ustawiona flaga BEV, oznaczająca że system jest w fazie bootowania wszystkie procedury wyjątków i przerwań są wykonywane z adresów w tym segmencie. Po zakończeniu bootowania ten segment jest nieużywany.
• Ostatnim segmentem jądra jest kseg2. Jądro ma w nim pełną dowolność w mapowaniu stron, wykorzystywany jest TLB oraz pamięć cache. Rozmiar tego segmentu to 1 GB.

Podsumowanie

Trzy opisane w tym tekście platformy dosyć odmiennie podchodzą do kwestii organizacji pamięci adresowej. sun4u oraz x86 dają stosunkowo duża dowolność pozwalając umieścić jądro zarówno w osobnej przestrzeni adresowej jak i w tej samej co program. x86 dodatkowo wspiera (nie licząc trybu IA-32e) segmentację. Dużo mniejsza dowolność jest w przypadku MIPS gdzie podział na segmenty jest odgórny. Inna sprawa, że w praktyce i tak wszystkie systemy (nie licząc tych eksperymentalnych) korzystają z tego jednego, najlepszego rozwiązania dla danej platformy.