Dlaczego (nie) segmentacja?


42

Studiuję systemy operacyjne i architekturę x86, a kiedy czytałem o segmentacji i stronicowaniu, naturalnie byłem ciekawy, jak nowoczesne systemy operacyjne obsługują zarządzanie pamięcią. Z tego, co znalazłem, Linux i większość innych systemów operacyjnych zasadniczo unika segmentacji na rzecz stronicowania. Kilka powodów, dla których znalazłem to prostota i przenośność.

Jakie praktyczne zastosowania ma segmentacja (x86 lub inna) i czy kiedykolwiek zobaczymy, że używają jej solidne systemy operacyjne, czy też nadal będą faworyzować system oparty na stronicowaniu.

Teraz wiem, że jest to obciążone pytanie, ale jestem ciekawy, jak poradzić sobie z segmentacją w nowo opracowanych systemach operacyjnych. Czy faworyzowanie stronicowania ma tyle sensu, że nikt nie rozważy bardziej „segmentowego” podejścia? Jeśli tak, dlaczego?


A kiedy mówię o „unikaniu” segmentacji, sugeruję, że Linux używa go tylko w takim stopniu, w jakim jest to konieczne. Tylko 4 segmenty dla segmentów kodu / danych użytkownika i jądra. Czytając dokumentację Intela, miałem wrażenie, że segmentacja została zaprojektowana z myślą o bardziej niezawodnych rozwiązaniach. Z drugiej strony wielokrotnie mówiono mi, jak skomplikowane może być x86.


Tę ciekawą anegdotę znalazłem po powiązaniu z oryginalnym „ogłoszeniem” Torvalda dla Linuksa. Powiedział to kilka postów później:

Po prostu powiedziałbym, że przeniesienie jest niemożliwe. Przeważnie jest w C, ale większość ludzi nie nazwałaby tego, co piszę. Wykorzystuje każdą możliwą funkcję 386, jaką mogłem znaleźć, ponieważ był to również projekt, aby nauczyć mnie o 386. Jak już wspomniano, używa MMU , zarówno dla stronicowania (jeszcze nie na dysk), jak i segmentacji. To segmentacja sprawia, że ​​NAPRAWDĘ zależy od niej 386 (każde zadanie ma segment 64 MB na kod i dane - maksymalnie 64 zadania w 4 Gb. Każdy, kto potrzebuje więcej niż 64 Mb / zadanie - twarde pliki cookie).

Wydaje mi się, że moje własne eksperymenty z x86 skłoniły mnie do zadania tego pytania. Linus nie miał StackOverflow, więc po prostu zaimplementował go, aby go wypróbować.


Jaką książkę przeczytałeś?

1
Czytam wiele książek. Zacząłem zadawać sobie to pytanie, czytając instrukcję Intel Systems Programming (vol. 3), ale przeczytałem trochę o zarządzaniu pamięcią w systemie Linux w „Understanding the Linux Kernel” i innych źródłach online.
Pan Shickadance,

W szczególności czytałem sekcję Tabele deskryptorów lokalnych i byłem ciekawy, w jaki sposób używały ich systemy operacyjne.
Pan Shickadance,

1
OpenBSD łączy segmentację i stronicowanie x86, aby uzyskać symulację bitów NX (funkcja bezpieczeństwa, która zabrania wykonywania stron danych). Może być używany również przez PaX.

Nic nie wiem na ten temat. Właśnie wpisałem zapytanie, aby zobaczyć odpowiedzi na skargi dotyczące wszystkich obecnie używanych systemów operacyjnych. Patrząc na skargi, większość osób korzysta z komputera, a teraz tabletu do kilku konkretnych zadań. Dlaczego więc nie przydzielić więcej pamięci, aby szybciej wykonywać te zadania, zamiast dawać do niej dostęp wszystkim bzdurom z urządzeń peryferyjnych?

Odpowiedzi:


31

Dzięki segmentacji możliwe byłoby na przykład umieszczenie każdego dynamicznie przydzielanego obiektu (malloc) we własnym segmencie pamięci. Sprzęt automatycznie sprawdza limity segmentów, a cała klasa błędów bezpieczeństwa (przepełnienia bufora) zostanie wyeliminowana.

Ponadto, ponieważ wszystkie przesunięcia segmentów zaczynają się od zera, cały skompilowany kod byłby automatycznie niezależny od pozycji. Wywołanie do innej biblioteki DLL sprowadzałoby się do dalekiego wywołania ze stałym przesunięciem (w zależności od wywoływanej funkcji). To znacznie uprościłoby konsolidatory i programy ładujące.

Dzięki 4 pierścieniom ochronnym można opracować bardziej szczegółową kontrolę dostępu (z przywoływaniem masz tylko 2 poziomy ochrony: użytkownik i administrator) oraz bardziej niezawodne jądra systemu operacyjnego. Na przykład tylko pierścień 0 ma pełny dostęp do sprzętu. Dzieląc jądro systemu operacyjnego i sterowniki urządzeń na pierścienie 0 i 1, można stworzyć bardziej niezawodny i bardzo szybki system operacyjny mikrojądra, w którym większość odpowiednich kontroli dostępu przeprowadzałaby HW. (Sterowniki urządzeń mogą uzyskać dostęp do sprzętu poprzez bitmapę dostępu we / wy w TSS.)

Jednak .. x86 jest nieco ograniczony. Ma tylko 4 „wolne” rejestry segmentów danych; ich ponowne załadowanie jest dość drogie i można jednocześnie uzyskać dostęp tylko do 8192 segmentów. (Zakładając, że chcesz zmaksymalizować liczbę dostępnych obiektów, więc GDT przechowuje tylko deskryptory systemowe i deskryptory LDT).

Teraz w trybie 64-bitowym segmentacja jest opisywana jako „starsza”, a sprawdzanie limitów sprzętowych odbywa się tylko w ograniczonych okolicznościach. IMHO, DUŻY błąd. Właściwie nie obwiniam Intela, głównie obwiniam programistów, z których większość uważała, że ​​segmentacja była „zbyt skomplikowana” i tęskniła za płaską przestrzenią adresową. Obwiniam także autorów systemu operacyjnego, którym brakowało wyobraźni, aby dobrze wykorzystać segmentację. (AFAIK, OS / 2 był jedynym systemem operacyjnym, który w pełni wykorzystywał funkcje segmentacji.)


1
Dlatego zostawiłem to otwarte. Z pewnością będzie kilka różnych
podejść do

1
@zvrba: Co za wspaniałe wytłumaczenie !!! Dzięki za to. Teraz mam wątpliwości: czy nie sądzisz, że INTEL mógł wygrać wielką nagrodę, sprawiając, że segmenty się nie nakładają, a 4 GB jest w stanie przy pomocy stronicowania? Mam na myśli, jak zrozumiałem, „segmentacja z stronicowaniem” jest w stanie adresować maksymalnie 4 GB przestrzeni adresowej pamięci wirtualnej. I to są orzeszki ziemne !!! Wyobraź sobie, że możesz mieć segmenty kodu, stosu i danych o wielkości 4 GB każdy i nie nakładać się ani nakładać, tak jak potrzebujesz! Byłby to wówczas duży sukces, bez konieczności wzywania pełnej architektury 64-bitowej w dzisiejszych czasach.
fante

1
Fantastyczne wyjaśnienie, dlaczego segmentacja jest dobra. To okropny wstyd, że upadł na bok. Oto opracowanie zawierające więcej szczegółów dla tych, którzy chcą dowiedzieć się więcej.
PKB2

1
Nic dziwnego, że kochałem OS / 2! Co za smutna utrata naprawdę wartościowej technologii dzięki ignorancji i marketingowi.
iluminuj

Każdy, kto uważa segmentację za dobry pomysł, nie może być na tyle stary, aby pamiętać, jak straszna jest segmentacja. To okropne. Praktycznie cały kod C, jaki kiedykolwiek napisano, wymaga płaskiej przestrzeni adresowej. Wygodnie jest patrzeć na wskaźnik i po prostu zobaczyć jego adres, nie trzeba zagłębiać się w bazę segmentów, zakładając, że jest to nawet możliwe, czego nie ma w trybie segmentacji w trybie chronionym x86, chyba że jądro pozwala zobaczyć jakoś, najprawdopodobniej z bardzo drogim wywołaniem systemowym. Zamiana nie jest możliwa w przypadku segmentów, chyba że zamienisz całe segmenty. Przywoływanie jest znacznie lepsze.
doug65536

25

Krótka odpowiedź jest taka, że ​​segmentacja to włamanie, które powoduje, że procesor z ograniczoną zdolnością adresowania pamięci przekracza te limity.

W przypadku 8086 na chipie było 20 linii adresowych, co oznacza, że ​​mógł on fizycznie uzyskać dostęp do 1 MB pamięci. Jednak wewnętrzna architektura opierała się na adresowaniu 16-bitowym, prawdopodobnie ze względu na chęć zachowania spójności z 8080. Zestaw instrukcji zawierał rejestry segmentów, które byłyby połączone z indeksami 16-bitowymi, aby umożliwić adresowanie pełnego 1 MB pamięci . 80286 rozszerzył ten model o prawdziwą MMU, aby obsługiwać ochronę opartą na segmentach i adresowanie większej ilości pamięci (iirc, 16 Mb).

W przypadku PDP-11 późniejsze modele procesora zapewniły segmentację na przestrzenie instrukcji i danych, ponownie w celu obsługi ograniczeń 16-bitowej przestrzeni adresowej.

Problem z segmentacją jest prosty: Twój program musi jawnie obejść ograniczenia architektury. W przypadku 8086 oznaczało to, że największy ciągły blok pamięci, do którego można było uzyskać dostęp, wynosił 64k. jeśli chcesz uzyskać dostęp do większej ilości danych, musisz zmienić rejestry segmentów. Co dla programisty C oznaczało, że musisz powiedzieć kompilatorowi C, jakie wskaźniki powinien wygenerować.

O wiele łatwiej było zaprogramować MC68k, który miał 32-bitową architekturę wewnętrzną i 24-bitową fizyczną przestrzeń adresową.


5
Ok, to wszystko ma sens. Jednak czytając dokumenty Intela, można by pomyśleć, że segmenty mogłyby faktycznie zostać wykorzystane do zwiększenia poziomu ochrony sprzętu przed błędami programu. W szczególności sekcja 3.2.3 Przewodnika programowania systemów - czy są zalety modelu wielosegmentowego? Czy słuszne byłoby stwierdzenie, że Linux używa chronionego płaskiego modelu? (sekcja 3.2.2)
Pan Shickadance,

3
Minęło dużo czasu, odkąd zwróciłem uwagę na szczegóły architektury pamięci Intel, ale nie sądzę, że architektura segmentowa zapewniłaby lepszą ochronę sprzętu. Jedyną prawdziwą ochroną, jaką może zapewnić MMU, jest oddzielenie kodu i danych, zapobiegając atakom na przepełnienie bufora. I uważam , że można to kontrolować bez segmentów za pomocą atrybutów na poziomie strony. Można teoretycznie ograniczyć dostęp do obiektów, tworząc osobny segment dla każdego, ale nie sądzę, żeby to było rozsądne.

1
Dzięki, przywróciłeś wszystkie stłumione wspomnienia związane z przetwarzaniem obrazu w pamięci segmentowej - to będzie oznaczało więcej terapii!
Martin Beckett,

10
Całkowicie źle zrozumiałeś segmentację. W 8086 mógł to być hack; 80286 wprowadził tryb chroniony, w którym było to kluczowe dla ochrony; w 80386 był jeszcze bardziej rozbudowany, a segmenty mogą być większe niż 64kB, nadal z korzyścią z kontroli sprzętu. (BTW, 80286 NIE posiadało MMU.)
zvrba

2
W 1985 roku, kiedy wprowadzono 386, przestrzeń adresowa 4 GiB została uznana za ogromną. Pamiętaj, że dysk twardy 20 MiB był w tym czasie dość duży i nadal nie było niczym niezwykłym, że systemy były wyposażone tylko w dyskietki. 3,5-calowy FDD został wprowadzony w 1983 r., A jego sformatowana pojemność wynosi aż 360 KB. (1,44 MB 3,5-calowe dyski FDD stały się dostępne w 1986 r.) W ramach błędu eksperymentu wszyscy myśleli o 32-bitowej przestrzeni adresowej, tak jak obecnie myślimy 64 bitów: fizycznie dostępny, ale tak duży, że jest praktycznie nieskończony.
CVn

15

Dla 80x86 dostępne są 4 opcje - „nic”, tylko segmentacja, tylko stronicowanie oraz zarówno segmentacja, jak i stronicowanie.

W przypadku „nic” (bez segmentacji lub stronicowania) nie ma łatwego sposobu na ochronę procesu przed samym sobą, żadnego łatwego sposobu na ochronę procesów przed sobą, żadnego sposobu radzenia sobie z takimi rzeczami, jak fragmentacja fizycznej przestrzeni adresowej, żaden sposób uniknięcia pozycji niezależny kod itp. Mimo tych wszystkich problemów może (teoretycznie) być użyteczny w niektórych sytuacjach (np. urządzenie osadzone, które uruchamia tylko jedną aplikację; lub może coś, co korzysta z JIT i i tak wszystko wirtualizuje).

Tylko do segmentacji; prawie rozwiązuje problem „chroń proces przed samym sobą”, ale wymaga wielu obejść, aby był użyteczny, gdy proces chce użyć więcej niż 8192 segmentów (zakładając jeden LDT na proces), co powoduje, że jest on w większości zepsuty. Prawie rozwiązujesz problem „ochrony procesów przed sobą”; ale różne programy działające na tym samym poziomie uprawnień mogą ładować / wykorzystywać swoje segmenty (istnieją sposoby na obejście tego - modyfikowanie wpisów GDT podczas transferów kontrolnych i / lub używanie LDT). W większości rozwiązuje również problem „kodu niezależnego od pozycji” (może powodować problem z „kodem zależnym od segmentu”, ale jest to znacznie mniej znaczące). Nie robi nic w przypadku problemu „fragmentacji fizycznej przestrzeni adresowej”.

Tylko do stronicowania; nie rozwiązuje problemu „ochrony procesu przed samym sobą” (ale bądźmy szczerzy, jest to tak naprawdę tylko problem do debugowania / testowania kodu napisanego w niebezpiecznych językach, i jest o wiele potężniejsze narzędzia, takie jak valgrind). Całkowicie rozwiązuje problem „ochrony procesów przed sobą”, całkowicie rozwiązuje problem „kodu niezależnego od pozycji” i całkowicie rozwiązuje problem „fragmentacji fizycznej przestrzeni adresowej”. Jako dodatkowy bonus otwiera kilka bardzo potężnych technik, które nie są tak praktyczne bez stronicowania; w tym rzeczy takie jak „kopiuj przy zapisie”, pliki mapowane w pamięci, wydajna obsługa przestrzeni wymiany itd.

Można by pomyśleć, że zastosowanie zarówno segmentacji, jak i stronicowania zapewniłoby korzyści obu; i teoretycznie może, z tą różnicą, że jedyną korzyścią wynikającą z segmentacji (której nie da się lepiej przywoływać) jest rozwiązanie problemu „ochrony procesu przed samym sobą”, na którym tak naprawdę nikogo nie obchodzi. W praktyce dostajesz złożoność obu i koszty ogólne obu, dla bardzo małej korzyści.

To dlatego prawie wszystkie systemy operacyjne zaprojektowane dla 80x86 nie używają segmentacji do zarządzania pamięcią (używają jej do takich rzeczy jak na procesor i pamięć na zadania, ale to głównie dla wygody, aby uniknąć konsumowania bardziej przydatnego rejestru ogólnego przeznaczenia dla tych rzeczy).

Oczywiście producenci procesorów nie są głupi - nie zamierzają poświęcać czasu i pieniędzy na optymalizację czegoś, o czym wiedzą, że nikt ich nie używa (zamiast tego zoptymalizują coś, z czego prawie wszyscy korzystają). Z tego powodu producenci procesorów nie optymalizują segmentacji, co powoduje, że segmentacja jest wolniejsza niż mogłaby, co sprawia, że ​​twórcy systemów operacyjnych chcą tego jeszcze bardziej uniknąć. Przeważnie utrzymywali segmentację tylko dla kompatybilności wstecznej (co jest ważne).

W końcu AMD zaprojektowało długi tryb. 64-bitowy kod nie miał się czym martwić, więc (w przypadku kodu 64-bitowego) AMD pozbyło się jak największej segmentacji. Dało to twórcom systemów operacyjnych jeszcze jeden powód (brak łatwego sposobu przeniesienia kodu przeznaczonego do segmentacji do wersji 64-bitowej), aby nadal unikać segmentacji.


13

Jestem raczej zaskoczony, że przez cały czas, odkąd zadano to pytanie, nikt nie wspominał o pochodzeniu segmentowanych architektur pamięci i prawdziwej mocy, na którą mogą sobie pozwolić.

Pierwotnym systemem, który albo wymyślił, albo przerobił na użyteczną formę, wszystkie funkcje związane z projektowaniem i wykorzystaniem segmentowanych systemów stronicowanej pamięci wirtualnej (wraz z symetrycznym wieloprocesowym przetwarzaniem i hierarchicznymi systemami plików) był Multics (i patrz także strona Multicians ). Segmentowana pamięć pozwala Multicsowi zaoferować użytkownikowi widok, że wszystko jest w (wirtualnej) pamięci, i pozwala na najwyższy poziom współdzielenia wszystkiegow formie bezpośredniej (tj. bezpośrednio adresowalnej w pamięci). System plików staje się po prostu mapą do wszystkich segmentów w pamięci. Przy prawidłowym stosowaniu w sposób systematyczny (jak w Multics) pamięć segmentowa uwalnia użytkownika od wielu obciążeń związanych z zarządzaniem pamięcią wtórną, udostępnianiem danych i komunikacją między procesami. Inne odpowiedzi dały do ​​zrozumienia, że ​​segmentacja pamięci jest trudniejsza w użyciu, ale to po prostu nieprawda, a firma Multics udowodniła to z wielkim powodzeniem dekady temu.

Intel stworzył spulchnioną wersję pamięci segmentowej 80286, która choć jest dość potężna, jej ograniczenia uniemożliwiły wykorzystanie jej do czegokolwiek naprawdę przydatnego. 80386 poprawił te ograniczenia, ale siły rynkowe w tamtym czasie prawie uniemożliwiły sukces jakiegokolwiek systemu, który mógłby naprawdę skorzystać z tych ulepszeń. Od lat wydaje się, że zbyt wiele osób nauczyło się ignorować lekcje z przeszłości.

Intel również próbował wcześnie zbudować bardziej wydajną super-mikro zwaną iAPX 432 , która w tym czasie znacznie przewyższałaby wszystko inne, a także posiadała segmentową architekturę pamięci i inne funkcje silnie ukierunkowane na programowanie obiektowe. Oryginalna implementacja była jednak po prostu zbyt wolna i nie podjęto żadnych dalszych prób jej naprawy.

Bardziej szczegółowe omówienie wykorzystania segmentacji i stronicowania przez Multics można znaleźć w artykule Paula Greena Pamięć wirtualna Multics - samouczek i refleksje


1
Świetne informacje i doskonałe argumenty. Dzięki za linki, są bezcenne !!!
fante

1
Dziękujemy za link do Multics i bardzo pouczającą odpowiedź! Najwyraźniej segmentacja była lepsza pod wieloma względami od tego, co robimy teraz.
PKB2

1
Twoja odpowiedź jest prawdziwym klejnotem. Dziękuję bardzo za podzielenie się tymi spostrzeżeniami, które utraciliśmy. Sprawia, że ​​pragnę powrotu do segmentacji poprzez opracowanie odpowiedniego systemu operacyjnego, który mógłby skłonić do udoskonalenia sprzętu. Dzięki takiemu podejściu można poprawić naprawdę wiele problemów! Brzmi nawet tak, jakbyśmy mogli uzyskać prawdziwe języki OOP przy znacznie wyższych poziomach wydajności i na gołym metalu z segmentacją.
iluminuj

6

Segmentacja polegała na włamaniu / obejściu pozwalającym na rozwiązanie do 1 MB pamięci przez 16-bitowy procesor - zwykle tylko 64K pamięci byłoby dostępne.

Gdy pojawiły się procesory 32-bitowe, można było zaadresować do 4 GB pamięci za pomocą płaskiego modelu pamięci i nie było już potrzeby segmentacji - Rejestry segmentów zostały ponownie przeznaczone jako selektory GDT / stronicowania w trybie chronionym (chociaż można to zrobić mają tryb chroniony 16-bitowy).

Również tryb płaskiej pamięci jest znacznie wygodniejszy dla kompilatorów - możesz pisać 16-bitowe programy segmentowane w C , ale jest to trochę uciążliwe. Płaski model pamięci ułatwia wszystko.


Czy wiele można powiedzieć o „ochronie” zapewnianej przez segmentację, gdy zamiast tego możemy po prostu użyć stronicowania?
Pan Shickadance,

1
@Pan. Segmentacja Shickadance nie zapewnia żadnej ochrony pamięci - Do ochrony pamięci potrzebny jest tryb chroniony, w którym można chronić pamięć za pomocą GDT lub stronicowania.
Justin

5

Niektóre architektury (jak ARM) w ogóle nie obsługują segmentów pamięci. Gdyby Linux był zależny od źródła od segmentów, nie mógłby być łatwo przeniesiony do tych architektur.

Patrząc na szerszy obraz, awaria segmentów pamięci ma związek z ciągłą popularnością C i arytmetyki wskaźników. Rozwój C jest bardziej praktyczny w przypadku architektury z płaską pamięcią; a jeśli chcesz mieć pamięć płaską, wybierasz stronicowanie pamięci.

Był czas na przełomie lat 80., kiedy Intel, jako organizacja, oczekiwał przyszłej popularności Ady i innych języków programowania wyższego poziomu. Z tego właśnie powodu pochodziły niektóre z ich bardziej spektakularnych awarii, takie jak okropna segmentacja pamięci APX432 i 286. Z 386 skapitulowali do programistów z płaską pamięcią; dodano stronicowanie i TLB, a rozmiary segmentów zmieniono na 4 GB. A następnie AMD w zasadzie usunął segmenty za pomocą x86_64, czyniąc base reg dont-care / implied-0 (z wyjątkiem fs? Dla TLS, myślę?)

Powiedziawszy to, zalety segmentów pamięci są oczywiste - przełączanie przestrzeni adresowej bez konieczności ponownego wypełniania TLB. Może kiedyś ktoś stworzy konkurencyjny pod względem wydajności procesor, który obsługuje segmentację, możemy zaprogramować dla niego system operacyjny zorientowany na segmentację, a programiści mogą zrobić Ada / Pascal / D / Rust / another-langage-that-not-need-flat- -programy pamięci dla tego.


1

Segmentacja stanowi ogromne obciążenie dla twórców aplikacji. Stąd duży nacisk na wyeliminowanie segmentacji.

Co ciekawe, często zastanawiam się, o ile lepszy byłby i86, gdyby Intel rozłożył całą starszą obsługę tych starych trybów. Tutaj lepiej oznaczałoby to niższą moc i być może szybszą pracę.

Wydaje mi się, że można argumentować, że Intel zalał mleko 16-bitowymi segmentami, co doprowadziło do buntu deweloperów. Ale spójrzmy prawdzie w oczy, przestrzeń adresowa na 64k to nic szczególnego, gdy spojrzysz na nowoczesną aplikację. W końcu musieli coś zrobić, ponieważ konkurencja mogła i skutecznie działała na rynku w związku z problemami przestrzeni adresowej i86.


1

Segmentacja prowadzi do wolniejszego tłumaczenia stron i wymiany

Z tych powodów segmentacja została znacznie zmniejszona na x86-64.

Główna różnica między nimi polega na tym, że:

  • stronicowanie dzieli pamięć na kawałki o stałej wielkości
  • segmentacja pozwala na różne szerokości dla każdej porcji

Chociaż może wydawać się mądrzejsze, aby mieć konfigurowalne szerokości segmentów, ponieważ zwiększasz rozmiar pamięci dla procesu, fragmentacja jest nieunikniona, np .:

|   | process 1 |       | process 2 |                        |
     -----------         -----------
0                                                            max

ostatecznie stanie się, gdy proces 1 rośnie:

|   | process 1        || process 2 |                        |
     ------------------  -------------
0                                                            max

dopóki podział jest nieunikniony:

|   | process 1 part 1 || process 2 |   | process 1 part 2 | |
     ------------------  -----------     ------------------
0                                                            max

W tym momencie:

  • jedynym sposobem na przetłumaczenie stron jest wyszukiwanie binarne na wszystkich stronach procesu 1, co wymaga niedopuszczalnego dziennika (n)
  • wymiana poza procesem 1 część 1 może być ogromna, ponieważ ten segment może być ogromny

Jednak w przypadku stron o stałym rozmiarze:

  • każde 32-bitowe tłumaczenie wykonuje tylko 2 odczyty pamięci: spacer po katalogu i stronie
  • każda zamiana jest akceptowalnym 4KiB

Kawałki pamięci o stałej wielkości są po prostu łatwiejsze do zarządzania i zdominowały obecny projekt systemu operacyjnego.

Zobacz także: https://stackoverflow.com/questions/18431261/how-does-x86-paging-work

Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.