Sidminne är ett sätt att organisera virtuellt minne , där virtuella adresser mappas till fysiska sida för sida. För 32-bitars x86-arkitektur är minsta sidstorlek 4096 byte. [ett]
Stöd för detta läge finns i de flesta 32-bitars och 64-bitars processorer. Detta läge är klassiskt för nästan alla moderna operativsystem, inklusive Windows och UNIX- familjen . Den utbredda användningen av ett sådant läge började med VAX - processorn och VMS OS från slutet av 1970-talet (enligt vissa källor, den första implementeringen). I x86-familjen har stöd dykt upp sedan 386-generationen, som också är den första 32-bitarsgenerationen.
Adressen som används i maskinkoden, dvs pekarens värde, kallas den "virtuella adressen".
Adressen som processorn lägger på bussen kallas den "linjära adressen" (som senare omvandlas till en fysisk adress).
Sidtabellsposten innehåller vanligtvis följande information:
Antalet poster i en tabell är begränsat och beror på poststorleken och sidstorleken. En flernivåorganisation av tabeller används, ofta 2 eller 3 nivåer, ibland 4 nivåer (för 64-bitars arkitekturer).
I fallet med 2 nivåer används en "katalog" med sidor, som lagrar poster som pekar på sidtabellernas fysiska adresser . Tabellerna innehåller poster som pekar på sidor med data.
När du använder 3-nivåorganisation läggs en superkatalog till som innehåller poster som pekar på flera kataloger.
De övre bitarna i den virtuella adressen anger numret på posten i katalogen, de mellersta anger numret på posten i tabellen, de nedre bitarna (adressen inuti sidan) går till den fysiska adressen utan översättning.
Formatet på tabellposter, deras storlek, sidstorlek och organisation av tabeller beror på typen av processor och ibland även på dess funktionssätt.
Historiskt sett har x86 använt 32-bitars PTE:er, 32-bitars virtuella adresser, 4-KB-sidor, 1024 tabellposter, tvånivåtabeller. De övre 10 bitarna av den virtuella adressen är numret på posten i katalogen, de nästa 10 är numret på posten i tabellen, de nedre 12 är adressen på sidan.
Från och med Pentium Pro stöder processorn 4 MB sidor. Men för att systemet och programmen som körs på det ska kunna använda sidor av denna storlek måste sidtekniken på 4 MB (hugepages) vara korrekt aktiverad och applikationen konfigurerad för att använda sidor av denna storlek.
x86-processorn i PAE -läge (Physical Address Extension) och i x86_64-läge (långt läge) använder 64-bitars PTE (av vilka inte alla fysiska adressbitar faktiskt används, från 36 i PAE till 48 i vissa x86_64), 32-bitars virtuella adresser, 4-KB-sidor, 512 tabellposter, trenivåtabeller med fyra kataloger och fyra superkatalogposter. De övre 2 bitarna i den virtuella adressen är numret på posten i superkatalogen, de nästa 9 bitarna finns i katalogen, de nästa 9 bitarna finns i tabellen. Den fysiska adressen till katalogen eller superkatalogen laddas in i ett av processorns kontrollregister .
När PAE används används 2MB-sidor istället för 4MB stora sidor. Se även PSE .
På x86_64-arkitekturen är det möjligt att använda sidor på 4 kilobyte (4096 byte), 2 megabyte och (i vissa AMD64) 1 gigabyte.
Om minnesåtkomsten inte kan översättas genom TLB , så kommer processormikrokoden åt sidtabellerna och försöker ladda PTE därifrån till TLB. Om problemen kvarstår efter ett sådant försök, utför processorn ett speciellt avbrott som kallas " sidfel " (sidfel). Hanteraren för detta avbrott finns i det virtuella minnesundersystemet i OS-kärnan.
Vissa processorer (MIPS) har inte mikrokod som kommer åt tabellen och genererar ett sidfel omedelbart efter en misslyckad uppslagning i TLB, åtkomst till tabellen och dess tolkning är redan tilldelad sidfelshanteraren. Detta berövar sidtabellerna kravet att överensstämma med ett hårdkodat format på hårdvarunivå.
Orsaker till sidfel ( sidfel ):
Kärnfelshanteraren kan ladda den önskade sidan från en fil eller från växlingsområdet (se växlingsområdet ), kan skapa en skrivskyddad kopia av sidan som är tillgänglig för skrivning, eller kan skapa ett undantag (i UNIX-termer - SIGSEGV- signalen ) i denna process.
Varje process har sin egen uppsättning sidtabeller . Sidkatalogregistret laddas om på varje processkontextväxel . Det är också nödvändigt att återställa den del av TLB som gäller för denna process.
I de flesta fall placeras OS-kärnan i samma adressutrymme som processerna, och de översta 1-2 gigabytena av 32-bitars adressutrymmet för varje process är reserverade för det. Detta görs för att undvika att byta sidtabell när du går in i och lämnar kärnan. Kärnsidor är markerade som otillgängliga för användarlägeskod.
Kärnregionens minne är ofta exakt detsamma för alla processer, men vissa underregioner i kärnregionen (till exempel Windows-regionen där grafikundersystemet och videodrivrutinen finns) kan vara olika för olika grupper av processer (sessioner).
Eftersom kärnminnet är detsamma för alla processer, behöver motsvarande TLB:er inte laddas om efter en processväxling. För denna optimering stöder x86 den "globala" flaggan på PTE.
Sidfelshanteraren i kärnan kan läsa den givna sidan från filen.
Detta leder till möjligheten att enkelt implementera minneskartade filer. Begreppsmässigt är detta detsamma som att allokera minne och läsa in en del av en fil i den, med skillnaden att läsningen utförs implicit "på begäran", uttryckt som ett sidfel när man försöker komma åt den.
Den andra fördelen med detta tillvägagångssätt är - i fallet med en skrivskyddad visning - att samma fysiska minne delas mellan alla processer som visar en given fil (varje process har sitt eget tilldelade minne).
Den tredje fördelen är möjligheten att "kassera" några av de mappade sidorna utan att byta ut dem till det växlingsutrymme som krävs för tilldelat minne. Vid upprepat behov av en sida kan den snabbt laddas från filen igen.
Den fjärde fördelen är att diskcachen inte används i detta läge, vilket innebär besparingar på att kopiera data från cachen till den begärda regionen. Fördelarna med en diskcache, som optimerar små operationer, samt upprepad läsning av samma data, försvinner helt när man läser hela sidor, och ännu mer grupper av sidor, medan nackdelen med obligatorisk extra kopiering kvarstår.
Minnesmappade filer används av Windows och UNIX operativsystem för att ladda körbara moduler och dynamiska bibliotek. De används också av GNU grep- verktyget för att läsa indatafilen, samt för att ladda typsnitt i ett antal grafiska undersystem.
En stor fördel med sökt virtuellt minne jämfört med segmenterat är frånvaron av "nära" och "fjärr"-pekare.
Närvaron av sådana koncept i programmering minskar tillämpligheten av pekarritmetik och leder till enorma problem med kodportabilitet från/till sådana arkitekturer. Så till exempel utvecklades en betydande del av programvara med öppen källkod ursprungligen för segmentlösa 32-bitars plattformar med sidminne och kan inte överföras till segmentarkitekturer utan allvarlig omarbetning.
Dessutom har segmentarkitekturer det svåraste problemet SS != DS, som var allmänt känt i början av 1990-talet inom programmering under 16-bitarsversioner av Windows. Detta problem leder till svårigheter i implementeringen av dynamiska bibliotek, eftersom de har sin egen DS och SS för den nuvarande processen, vilket leder till omöjligheten att använda "nära" pekare i dem. Att ha en egen DS i bibliotek kräver också patchar (MakeProcInstance) för att ställa in rätt DS-värde för återuppringningar från biblioteket till den anropande applikationen.
Stöd för minneskartade filer kräver att OS-kärnan stöder strukturen "en uppsättning fysiska sidor som innehåller segment av en given fil." Kartläggning av en fil i minnet görs genom att fylla tabellposter med länkar till sidor i en given struktur.
Det är ganska uppenbart att denna struktur är en färdig diskcache. Att använda det som en cache löser också problemet med koherens mellan en läs-/skrivfil och en minnesmappad fil.
Således, cachade I/O-sökvägar till en diskfil (FsRtlCopyRead på Windows och generic_file_read() på Linux) implementeras som kopior av data till fysiska sidor mappade till en fil.
Denna cache-organisation är den enda i Windows, detta operativsystem har inte en klassisk blockdiskcache alls. Filsystemmetadata cachelagras genom att skapa falska filer (IoCreateStreamFileObject) och skapa en sidcache för dem.
Ursprungligen hade x86-arkitekturen inte en flagga för "sidan inte körbar" ( NX ).
Stöd för denna flagga dök upp i x86-arkitekturen som en del av PAE -läget (Physical Address Extension) i Pentium 4-generationen, under stort tryck från säkerhetsspecialister (se NTBugTraq-arkiven). Genom att ställa in denna flagga på stack- och heapsidorna kan man implementera skydd för körning av hårdvarudata, vilket gör det omöjligt för många typer av skadlig programvara att fungera, inklusive till exempel skadlig exploatering av många brister i Internet Explorer (december 2008-fel, se MS kunskap bas kan inte användas om DEP är aktiverat ).
Windows PAE- stöd , som möjliggör dataexekveringsskydd , introducerades i Windows 2000 och är aktiverat som standard på serverversioner av Windows och inaktiverat på klientversioner.
PCI-enheter, inklusive grafikkortsminne, stöder vanligtvis bara 32-bitars adresser. Därför måste de ges fysiska adresser under 4 GB-märket. Denna "öppning" minskar mängden synligt fysiskt minne under 4 GB-märket till cirka 3,2 GB. Resten av det fysiska minnet mappas om av kontrollern över 4 GB-märket.
All minnesåtkomst över 4 GB (dvs. mer än cirka 3,2 GB) kräver att kontrollern (dvs. den norra bryggan på chipsetet) stöder denna konfiguration. Moderna styrkretsar (till exempel Intel G33) har sådant stöd.
Det kräver också en BIOS-inställning som kallas minnesomappning som mappar region [3,2...4] till [4...4,8].
x86-processorn utanför PAE -läget använder 32-bitars PTE:er och fysiska adresser, det vill säga inget mer än 4 GB är tillgängligt för den (se även PSE-36 för en väg runt denna begränsning). För att kunna använda mer än cirka 3,2 GB minne i ett operativsystem måste det alltså stödja PAE. För Windows är det här startalternativet, för Linux är det här alternativet för att bygga kärnan.
Dessutom har Microsoft tvångsinaktiverat stöd för fysiska adresser över 4 GB av politiska och marknadsföringsmässiga skäl i följande operativsystem:
Stöd för fysiska adresser över 4 GB finns i följande versioner:
För att använda minne över 3,2 GB i Windows behöver du alltså:
Men även på en "avskalad" version av Windows som inte stöder adresser över 4 GB, är det vettigt att alltid använda PAE eftersom (se ovan) Data Execution Protection ( DEP ) också kräver PAE. Aktivering av PAE kan göra att en liten mjukvara slutar fungera, till exempel Windows Mobile-emulatorn. Enligt den officiella versionen av Microsoft beror införandet av en gräns för adressutrymmet på 4 GB på det saknade eller dåliga stödet för 36-bitars adressutrymmet av vissa drivrutiner, detta bör man komma ihåg, på grund av hårdvarubegränsningar eller olämpligt drivrutiner är det omöjligt att aktivera PAE på versioner som stöder fysiska adresser högre än 4 GB. Möjligheten att aktivera eller inaktivera PAE beror inte på drivrutiner, men om drivrutinen för någon gammal PCI-utrustning inte korrekt stöder fysiska adresser som inte får plats i 32 bitar, kommer den här enheten inte att fungera korrekt och kan orsaka att hela datorn frysa.
| Aspekter av operativsystem | |||||
|---|---|---|---|---|---|
| |||||
| Typer |
| ||||
| Kärna |
| ||||
| Processledning _ |
| ||||
| Minneshantering och adressering | |||||
| Ladda och initieringsverktyg | |||||
| skal | |||||
| Övrig | |||||
| Kategori Wikimedia Commons Wikibooks Wiktionary | |||||