Intel x86 Assembly Language & Microarchitecture
Paging - Virtuele adressering en geheugen

Invoering

Geschiedenis

De eerste computers

Vroege computers hadden een geheugenblok waarin de programmeur code en gegevens invoerde en de CPU werd binnen deze omgeving uitgevoerd. Gezien het feit dat de computers toen erg duur waren, was het jammer dat het één taak zou volbrengen, stop en wacht tot de volgende taak erin werd geladen en die vervolgens zou verwerken.

Multi-user, multi-verwerking

Dus computers werden snel geavanceerder en ondersteunden meerdere gebruikers en / of programma's tegelijkertijd - maar dat was het moment waarop problemen ontstonden met het eenvoudige idee van "één blok geheugen". Als een computer twee programma's tegelijkertijd zou uitvoeren, of hetzelfde programma voor meerdere gebruikers zou draaien - wat natuurlijk afzonderlijke gegevens voor elke gebruiker zou vereisen - dan werd het beheer van dat geheugen kritisch.

Voorbeeld

Bijvoorbeeld: als een programma is geschreven om te werken op geheugenadres 1000, maar daar al een ander programma is geladen, kan het nieuwe programma niet worden geladen. Een manier om dit op te lossen zou zijn om programma's te laten werken met "relatieve adressering" - het maakte niet uit waar het programma werd geladen, het deed gewoon alles met betrekking tot het geheugenadres waarin het was geladen. Maar dat vereiste hardware-ondersteuning.

verfijning

Naarmate computerhardware geavanceerder werd, kon het grotere geheugenblokken ondersteunen, waardoor meer gelijktijdige programma's mogelijk werden, en werd het lastiger om programma's te schrijven die niet interfereerden met wat al geladen was. Eén verdwaalde geheugenreferentie zou niet alleen het huidige programma, maar elk ander programma in het geheugen kunnen verlagen - inclusief het besturingssysteem zelf!

Oplossingen

Wat nodig was, was een mechanisme waarmee blokken geheugen dynamische adressen konden hebben. Op die manier kan een programma worden geschreven om te werken met zijn blokken geheugen op adressen die het herkende - en niet in staat zijn om toegang te krijgen tot andere blokken voor andere programma's (tenzij enige samenwerking het toestond).

Segmentatie

Een mechanisme dat dit implementeerde was Segmentatie. Daardoor konden geheugenblokken van alle verschillende groottes worden gedefinieerd en zou het programma moeten definiëren tot welk segment het altijd toegang wilde hebben.

Problemen

Deze techniek was krachtig - maar zijn flexibiliteit was een probleem. Aangezien Segmenten het beschikbare geheugen in essentie onderverdeelde in brokken van verschillende grootte, was het geheugenbeheer voor die segmenten een probleem: toewijzing, deallocatie, groeiend, krimpen, fragmentatie - alle vereiste geavanceerde routines en soms massaal kopiëren om te implementeren.

paging

Een andere techniek verdeelde al het geheugen in blokken van gelijke grootte, "Pages" genoemd, waardoor de toewijzings- en deallocatieroutines zeer eenvoudig waren en groeide, krimpt en versplinterde (behalve interne fragmentatie, wat slechts een probleem is van) verspilling).

Virtuele adressering

Door het geheugen in deze blokken te verdelen, kunnen ze naar behoefte aan verschillende programma's worden toegewezen met elk adres waar het programma het nodig had. Deze "mapping" tussen het fysieke adres van het geheugen en het gewenste adres van het programma is zeer krachtig en vormt de basis voor het geheugenbeheer van elke grote processor (Intel, ARM, MIPS, Power et. Al.).

Ondersteuning voor hardware en besturingssystemen

De hardware voerde de remapping automatisch en continu uit, maar vereiste geheugen om de tabellen te definiëren van wat te doen. Natuurlijk moest het huishouden dat bij deze hermapping hoort, door iets worden bestuurd. Het besturingssysteem moet het geheugen desgewenst verdelen en de gegevenstabellen beheren die de hardware nodig heeft om de programma's te ondersteunen.

Oproepfuncties

Als de hardware dit opnieuw in kaart kon brengen, wat stond het dan toe? De belangrijkste driver was multiprocessing - de mogelijkheid om meerdere programma's uit te voeren, elk met hun "eigen" geheugen, beschermd tegen elkaar. Maar twee andere opties omvatten "schaarse gegevens" en "virtueel geheugen".

multiprocessing

Elk programma kreeg zijn eigen, virtuele "adresruimte" - een reeks adressen waaraan fysiek geheugen kon worden toegewezen, op elk gewenst adres. Zolang er voldoende fysiek geheugen was om rond te gaan (zie "Virtueel geheugen" hieronder), konden meerdere programma's tegelijkertijd worden ondersteund.

Bovendien hadden die programma's geen toegang tot geheugen dat niet was toegewezen aan hun virtuele adresruimte - bescherming tussen programma's was automatisch. Als programma's moesten communiceren, konden ze het besturingssysteem vragen om een gedeeld geheugenblok te regelen - een blok fysiek geheugen dat tegelijkertijd in de adresruimten van twee verschillende programma's werd toegewezen.

Sparse gegevens

Het toestaan van een enorme virtuele adresruimte (typisch 4 GB, overeenkomend met de 32-bits registers die deze processoren meestal hadden) verspilt op zichzelf geen geheugen als grote delen van die adresruimte niet worden toegewezen. Dit maakt het mogelijk om enorme datastructuren te creëren waarbij alleen bepaalde onderdelen tegelijkertijd worden toegewezen. Stel je een driedimensionale reeks van 1.000 bytes in elke richting voor: dat zou normaal een miljard bytes kosten! Maar een programma zou een blok van zijn virtuele adresruimte kunnen reserveren om deze gegevens te "bewaren", maar alleen kleine secties toewijzen zoals ze waren ingevuld. Dit zorgt voor efficiënt programmeren, terwijl geen geheugen wordt verspild aan gegevens die nog niet nodig zijn.

Virtueel geheugen

Hierboven heb ik de term "Virtuele adressering" gebruikt om de virtueel-fysieke adressering door de hardware te beschrijven. Dit wordt vaak "virtueel geheugen" genoemd - maar die term komt correcter overeen met de techniek van het gebruik van virtuele adressering ter ondersteuning van het bieden van een illusie van meer geheugen dan daadwerkelijk beschikbaar is.

Het werkt als volgt:

• Naarmate programma's worden geladen en meer geheugen vragen, biedt het besturingssysteem het geheugen van wat het beschikbaar heeft. Naast het bijhouden van het toegewezen geheugen, houdt het besturingssysteem ook bij wanneer het geheugen daadwerkelijk wordt gebruikt - de hardware ondersteunt het markeren van gebruikte pagina's.
• Wanneer het besturingssysteem geen fysiek geheugen meer heeft, kijkt het naar al het geheugen dat het al heeft uitgegeven voor welke pagina het minst werd gebruikt, of niet het langst was gebruikt. Het slaat de inhoud van die specifieke pagina op de harde schijf op, onthoudt waar dat was, markeert het als "Niet aanwezig" voor de hardware voor de oorspronkelijke eigenaar en stelt vervolgens de pagina op nul en geeft het aan de nieuwe eigenaar.
• Als de oorspronkelijke eigenaar opnieuw toegang probeert te krijgen tot die pagina, meldt de hardware het besturingssysteem. Het besturingssysteem wijst vervolgens een nieuwe pagina toe (misschien moet u de vorige stap opnieuw uitvoeren!), Laadt de inhoud van de oude pagina en overhandigt de nieuwe pagina aan het oorspronkelijke programma.

  Het belangrijke punt om op te merken is dat aangezien elke pagina aan elk adres kan worden toegewezen en elke pagina dezelfde grootte heeft, de ene pagina net zo goed is als de andere - zolang de inhoud hetzelfde blijft!

• Als een programma toegang krijgt tot een niet-toegewezen geheugenlocatie, meldt de hardware het besturingssysteem zoals eerder. Deze keer merkt het OS dat het geen pagina was die was opgeslagen, dus herkent het als een bug in het programma en beëindigt het!

  Dit is eigenlijk wat er gebeurt als je app op mysterieuze wijze van je verdwijnt - misschien met een MessageBox van het besturingssysteem. Het is ook wat (vaak) een berucht Blue Screen of Sad Mac veroorzaakt - het buggy-programma was in feite een OS-stuurprogramma dat toegang kreeg tot geheugen dat het niet zou moeten!

Beslissen over oproepen

De hardware-architecten moesten een aantal grote beslissingen nemen over Paging, omdat het ontwerp rechtstreeks van invloed zou zijn op het ontwerp van de CPU! Een zeer flexibel systeem zou een hoge overhead hebben en grote hoeveelheden geheugen vereisen, alleen om de Paging-infrastructuur zelf te beheren.

Hoe groot moet een pagina zijn?

In hardware zou de eenvoudigste implementatie van Paging zijn om een adres te nemen en het in twee delen te verdelen. Het bovenste gedeelte zou een indicatie zijn van welke pagina moet worden geopend, terwijl het onderste gedeelte de index van de pagina voor de vereiste byte is:

+-----------------+------------+
| Page index      | Byte index |
+-----------------+------------+

Het werd echter snel duidelijk dat voor kleine pagina's uitgebreide indexen nodig waren voor elk programma: zelfs geheugen dat niet in kaart was gebracht, zou een vermelding in de tabel nodig hebben die dit aangeeft.

Dus in plaats daarvan wordt een gelaagde index gebruikt. Het adres is opgedeeld in meerdere delen (drie worden aangegeven in het onderstaande voorbeeld), en het bovenste deel (gewoonlijk een "Directory" genoemd) indexeert in het volgende deel enzovoort tot de laatste byte-index in de laatste pagina wordt gedecodeerd:

+-----------+------------+------------+
| Dir index | Page index | Byte index |
+-----------+------------+------------+

Dat betekent dat een Directory-index kan aangeven "niet in kaart gebracht" voor een groot deel van de adresruimte, zonder dat er meerdere Page-indexen nodig zijn.

Hoe het gebruik van de paginatabellen te optimaliseren?

Elke adrestoegang die de CPU zal maken, moet in kaart worden gebracht - het virtuele-naar-fysieke proces moet daarom zo efficiënt mogelijk zijn. Als het hierboven beschreven drieledige systeem zou worden geïmplementeerd, zou dat betekenen dat elke geheugentoegang eigenlijk drie toegangen zou zijn: één in de Directory; één in de paginatabel; en dan eindelijk de gewenste gegevens zelf. En als de CPU ook het huishouden moest uitvoeren, bijvoorbeeld om aan te geven dat deze pagina nu was geopend of weggeschreven, dan zou dat nog meer toegang vereisen om de velden bij te werken.

Het geheugen kan snel zijn, maar dit zou een drievoudige vertraging opleggen voor alle geheugentoegangen tijdens het oproepen! Gelukkig hebben de meeste programma's een "locality of scope" - dat wil zeggen, als ze toegang hebben tot één locatie in het geheugen, zullen toekomstige toegangen waarschijnlijk in de buurt zijn. En omdat pagina's niet te klein zijn, hoeft die kaartconversie alleen te worden uitgevoerd wanneer een nieuwe pagina wordt geopend: niet voor absoluut elke toegang.

Maar het zou nog beter zijn om een cache van recent geopende pagina's te implementeren, niet alleen de meest actuele. Het probleem zou zijn om bij te houden tot welke pagina's toegang was verkregen en wat niet - de hardware zou bij elke toegang door de cache moeten scannen om de waarde in het cachegeheugen te vinden. Dus de cache is geïmplementeerd als een content-adresseerbare cache: in plaats van toegang te krijgen op adres, wordt deze benaderd door content - als de gevraagde gegevens aanwezig zijn, wordt deze aangeboden, anders wordt een lege locatie gemarkeerd om in te vullen. De cache beheert dat allemaal.

Deze content-adresseerbare cache wordt vaak een Translation Lookaside Buffer (TLB) genoemd en moet door het besturingssysteem worden beheerd als onderdeel van het subsysteem Virtual Addressing. Wanneer de mappen of paginatabellen door het besturingssysteem worden gewijzigd, moet het de TLB op de hoogte stellen om zijn vermeldingen bij te werken of om ze simpelweg ongeldig te maken.

80386 Paging

Ontwerp op hoog niveau

De 80386 is een 32-bit processor, met een 32-bit adresseerbare geheugenruimte. De ontwerpers van het Paging-subsysteem merkten op dat een 4K-paginaontwerp op een behoorlijk nette manier in die 32-bits is afgebeeld - 10 bits, 10 bits en 12 bits:

+-----------+------------+------------+
| Dir index | Page index | Byte index |
+-----------+------------+------------+
 3         2 2          1 1          0  Bit
 1         2 1          2 1          0  number

Dat betekende dat de Byte-index 12 bits breed was, wat zou indexeren in een 4K-pagina. De directory- en pagina-indexen waren 10 bits, die elk in een tabel met 1.024 items zouden worden opgenomen - en als die tabelitems elk 4 bytes waren, zou dat 4K per tabel zijn: ook een pagina!

Dus dat deden ze:

• Elk programma zou zijn eigen directory hebben, een pagina met 1.024 pagina-items die elk gedefinieerd hadden waar de paginatabel van het volgende niveau was - als die er was.
• Als dat het geval was, zou die paginatabel 1.024 pagina-items hebben die elk gedefinieerd hadden waar de pagina op het laatste niveau was - als die er was.
• Als dat zo was, dan zou die pagina zijn Byte direct kunnen laten uitlezen.

Pagina-invoer

Zowel de map op het hoogste niveau als de paginatabel op het volgende niveau bestaat uit 1.024 pagina-invoer. Het belangrijkste deel van deze items is het adres van wat het indexeert: een paginatabel of een werkelijke pagina. Merk op dat dit adres niet de volledige 32 bits nodig heeft - omdat alles een pagina is, zijn alleen de top 20 bits belangrijk. De andere 12 bits in de pagina-invoer kunnen dus voor andere dingen worden gebruikt: of het volgende niveau zelfs aanwezig is; de huishouding of de pagina is geopend of beschreven; en zelfs of schrijven zelfs moet worden toegestaan!

+--------------+----+------+-----+---+---+
| Page Address | OS | Used | Sup | W | P |
+--------------+----+------+-----+---+---+
Page Address = Top 20 bits of Page Table or Page address
OS           = Available for OS use
Used         = Whether this page has been accessed or written to
Sup          = Whether this page is Supervisory - only accessible by the OS
W            = Whether this page is allowed to be Written
P            = Whether this page is even Present

Merk op dat als het P bit 0 is, de rest van de entry alles mag hebben wat het besturingssysteem daar wil plaatsen - zoals waar de inhoud van de pagina zich op de harde schijf zou kunnen bevinden!

Page Directory Base Register ( PDBR )

Als elk programma zijn eigen map heeft, hoe weet de hardware dan waar het in kaart moet worden gebracht? Aangezien de CPU slechts één programma tegelijk uitvoert, heeft deze een enkel besturingsregister voor het adres van de directory van het huidige programma. Dit is het Page Directory Base Register ( CR3 ). Terwijl het besturingssysteem tussen verschillende programma's wisselt, werkt het de PDBR met de relevante Page Directory voor het programma.

Paginafouten

Elke keer dat de CPU toegang tot het geheugen krijgt, moet hij het aangegeven virtuele adres in het juiste fysieke adres toewijzen. Dit is een proces in drie stappen:

1. Indexeer de top 10 bits van het adres in de pagina die wordt aangegeven door de PDBR om het adres van de juiste PDBR te krijgen;
2. Indexeer de volgende 10 bits van het adres in de door de map aangegeven pagina om het adres van de juiste pagina te krijgen;
3. Indexeer de laatste 12 bits van het adres om de gegevens uit die pagina te halen.

Omdat beide stappen 1. en 2. hierboven Pagina-invoer gebruiken, kan elke invoer een probleem aangeven:

• Het volgende niveau kan worden gemarkeerd als "Niet aanwezig";
• Het volgende niveau kan worden gemarkeerd als "Alleen lezen" - en de bewerking is een Write;
• Het volgende niveau kan worden gemarkeerd als "Supervisor" - en het is het programma dat toegang heeft tot het geheugen, niet het besturingssysteem.

Wanneer een dergelijk probleem door de hardware wordt opgemerkt, veroorzaakt dit in plaats van het voltooien van de toegang een fout: onderbreking # 14, de paginafout. Het vult ook enkele specifieke controleregisters in met de informatie waarom de fout is opgetreden: het adres waarnaar wordt verwezen; of het een Supervisortoegang was; en of het een schrijfpoging was.

Van het besturingssysteem wordt verwacht dat het die fout vasthoudt, de registers registreert en besluit wat te doen. Als het een ongeldige toegang is, kan het het foutprogramma beëindigen. Als het echter een toegang tot virtueel geheugen is, moet het besturingssysteem een nieuwe pagina toewijzen (die mogelijk een pagina moet verlaten die al in gebruik is!), Deze vullen met de vereiste inhoud (alle nullen of de vorige inhoud die van schijf is geladen) ), wijst u de nieuwe pagina toe aan de juiste paginatabel, markeert u deze als aanwezig en gaat u verder met de foutinstructie. Deze keer zal de toegang succesvol verlopen en het programma zal doorgaan zonder te weten dat er iets speciaals is gebeurd (tenzij de klok wordt bekeken!)

80486 Paging

Het 80486 Paging-subsysteem leek sterk op het 80386-subsysteem. Het was achterwaarts compatibel en de enige nieuwe functies waren om geheugencache-controle per pagina mogelijk te maken - de OS-ontwerpers konden specifieke pagina's markeren als niet in de cache te plaatsen, of een andere wegschrijven of wegschrijven gebruiken caching technieken.

In alle andere opzichten is het voorbeeld "80386 Paging" van toepassing.

Pentium paging

Toen het Pentium werd ontwikkeld, werden de geheugengroottes en de programma's die erin liepen groter. Het besturingssysteem moest meer en meer werken om het semafoonsubsysteem te onderhouden, alleen in het enorme aantal pagina-indexen dat moest worden bijgewerkt wanneer grote programma's of gegevenssets werden gebruikt.

Dus voegden de Pentium-ontwerpers een eenvoudige truc toe: ze plaatsten een extra beetje in de vermeldingen van de paginamap die aangaven of het volgende niveau een paginatabel was (zoals eerder) - of gingen rechtstreeks naar een pagina van 4 MB! Door het concept van 4 MB pagina's te hebben, zou het besturingssysteem geen paginatabel moeten maken en deze vullen met 1.024 items die in feite adressen 4K hoger indexeren dan de vorige.

Adresindeling

+-----------+----------------------+
| Dir Index | 4MB Byte Index       |
+-----------+----------------------+
 3         2 2                    0   Bit
 1         2 1                    0   number

Indeling van directoryvermeldingen

+-----------+----+---+------+-----+---+---+
| Page Addr | OS | S | Used | Sup | W | P |
+-----------+----+---+------+-----+---+---+
Page Addr = Top 20 bits of Page Table or Page address
OS        = Available for OS use
S         = Size of Next Level: 0 = Page Table, 1 = 4 MB Page
Used      = Whether this page has been accessed or written to
Sup       = Whether this page is Supervisory - onlly accessible by the OS
W         = Whether this page is allowed to be Written
P         = Whether this page is even Present

Dat had natuurlijk enkele gevolgen:

• De 4 MB-pagina moest beginnen op een 4 MB-adresgrens, net zoals de 4K-pagina's moesten beginnen op een 4K-adresgrens.
• Alle 4 MB moest tot een enkel programma behoren - of door meerdere worden gedeeld.

Dit was perfect voor gebruik met randapparatuur met een groot geheugen, zoals grafische adapters, die grote vensters met adresruimte hadden die moesten worden toegewezen om het besturingssysteem te kunnen gebruiken.

Physical Address Extension (PAE)

Invoering

Naarmate de geheugenprijzen daalden, konden op Intel gebaseerde pc's steeds meer RAM-geheugen betaalbaar hebben, waardoor de problemen van veel gebruikers bij het uitvoeren van veel van de steeds grotere toepassingen die tegelijkertijd werden geproduceerd, werden verlicht. Hoewel virtueel geheugen het mogelijk maakte om geheugen vrijwel "aan te maken" - bestaande "oude" pagina-inhoud naar de harde schijf te wisselen om "nieuwe" gegevens toe te staan om op te slaan - vertraagde dit de uitvoering van de programma's omdat pagina "thrashing" voortdurend gegevens verwisselde aan en uit de harde schijf.

Meer RAM

Wat nodig was, was de mogelijkheid om toegang te krijgen tot meer fysiek RAM - maar het was al een 32-bit adresbus, dus elke toename zou grotere adresregisters vereisen. Of zou het? Bij het ontwikkelen van de Pentium Pro (en zelfs de Pentium M), als een tussenruimte totdat 64-bits processoren konden worden geproduceerd, om meer fysieke adresbits toe te voegen (waardoor meer fysiek geheugen mogelijk is) zonder het aantal registerbits te wijzigen. Dit kon worden bereikt omdat virtuele adressen toch aan fysieke adressen waren toegewezen - het enige dat moest veranderen, was het kaartsysteem.

Ontwerp

Het bestaande systeem heeft toegang tot maximaal 32 bits fysieke adressen. Om dit te verhogen was een volledige wijziging van de structuur voor pagina-invoer vereist, van 32 naar 64 bits. Er werd besloten om de minimale granulariteit op 4K-pagina's te houden, zodat de 64-bits invoer 52 bits adres en 12 bits controle zou hebben (zoals de vorige invoer 20 bits adres en 12 bits controle).

Met een 64-bits invoer, maar een paginagrootte van (nog steeds) 4K, betekende dat er slechts 512 vermeldingen per paginatabel of map zouden zijn, in plaats van de vorige 1.024. Dat betekende dat het 32-bits virtuele adres anders zou worden verdeeld dan voorheen:

+-----+-----------+------------+------------+
| DPI | Dir Index | Page Index | Byte Index |
+-----+-----------+------------+------------+
 3   3 2         2 2          1 1          0   Bit
 1   0 9         1 0          2 1          0   number

 DPI        = 2-bit index into Directory Pointer Table
 Dir Index  = 9-bit index into Directory
 Page Index = 9-bit index into Page Table
 Byte Index = 12-bit index into Page (as before)

Het hakken van een bit van zowel de Directory Index als de Page Index gaf twee bits voor een derde niveau van mapping: ze noemden dit de Page Directory Pointer Table (PDPT), een tabel van exact vier 64-bit Entries die vier Directories adresseerde in plaats van de vorige een. De PDBR ( CR3 ) wees nu in plaats daarvan naar de PDPT - die, aangezien CR3 slechts 32 bits was, in de eerste 4 GB RAM moest worden opgeslagen voor toegankelijkheid. Merk op dat, aangezien de lage bits van CR3 worden gebruikt voor besturing, de PDPT moet beginnen op een grens van 32 bytes.

Page Size Extension (PSE)

En omdat de vorige 4MB-pagina's zo'n goed idee waren, wilden ze grote pagina's opnieuw kunnen ondersteunen. Deze keer produceerde het verwijderen van de laatste laag van het laagsysteem echter geen 10 + 12 bit 4MB-pagina's, maar 9 + 12 bit 2MB-pagina's.

PSE-32 (en PSE-40)

Omdat de Physical Address Extension (PAE) -modus die werd geïntroduceerd in de Pentium Pro (en Pentum M) zo'n verandering was in het geheugenbeheersubsysteem van het besturingssysteem, besloten Intel toen de Pentium II werd ontworpen de "normale" paginamodus te verbeteren om ondersteuning van de nieuwe fysieke adresbits van de processor binnen de eerder gedefinieerde 32-bits invoer.

Ze realiseerden zich dat wanneer een 4MB-pagina werd gebruikt, het telefoonboekitem er als volgt uitzag:

+-----------+------------+---------+
| Dir Index |  Unused    | Control |
+-----------+------------+---------+

De Dir Index- en Control-gebieden van de Entry waren hetzelfde, maar het blok van ongebruikte bits daartussen - die door de Page Index zouden worden gebruikt als het bestond - was verspild. Dus besloten ze dat gebied te gebruiken om de bovenste fysieke adresbits boven 31 te definiëren !

+-----------+------+-----+---------+
| Dir Index |Unused|Upper| Control |
+-----------+------+-----+---------+

Hierdoor kon RAM boven 4 GB toegankelijk zijn voor besturingssystemen die de PAE-modus niet overnamen - met een beetje extra logica konden ze grote hoeveelheden extra RAM aan het systeem leveren, zij het niet meer dan de normale 4 GB voor elk programma. Aanvankelijk werden slechts 4 bits toegevoegd, waardoor 36-bits fysieke adressering mogelijk was, dus deze modus werd Page Size Extension 36 (PSE-36) genoemd. Het veranderde niet echt de paginagrootte, alleen de adressering.

De beperking hiervan was echter dat alleen 4MB-pagina's boven 4 GB konden worden gedefinieerd - 4K-pagina's waren niet toegestaan. De goedkeuring van deze modus was niet breed - het was naar verluidt langzamer dan het gebruik van PAE en Linux gebruikte het nooit.

Niettemin, in latere processors die nog meer Physical Address-bits hadden, hebben zowel AMD als Intel het PSE-gebied verbreed tot 8 bits, wat sommige mensen "PSE-40" noemden