Direkt minnesåtkomst

Den aktuella versionen av sidan har ännu inte granskats av erfarna bidragsgivare och kan skilja sig väsentligt från versionen som granskades den 31 oktober 2021; kontroller kräver 8 redigeringar .

Direkt minnesåtkomst ( eng.  direkt minnesåtkomst , DMA ) - ett datautbytesläge mellan datorenheter eller mellan en enhet och huvudminne , där den centrala processorenheten (CPU) inte deltar. Eftersom data inte skickas till och från CPU:n ökar överföringshastigheten.

Beskrivning av arbetet

Om du behöver fylla minnesceller placerade vid på varandra följande adresser, använd "burst" ( eng.  burst ) bussdriftsläge:

En liknande optimering av CPU med minne är extremt svår.

I den ursprungliga arkitekturen för IBM PC ( ISA-buss ) var DMA endast möjligt med en hårdvaru - DMA-styrenhet ( Intel 8237- chip ).

DMA-styrenheten kan komma åt systembussen oberoende av CPU:n och har flera register . DMA-styrenhetens register är tillgängliga för CPU:n för läsning och skrivning och används för att ställa in:

Tänk på processen att läsa data från enheten. CPU:n skriver värden till DMA-styrenhetens register, skickar ett kommando till enheten (till exempel en disk) för att läsa data. Enheten läser data (till exempel från disk) och skriver till sitt interna minne (buffert). DMA-styrenheten ställer in PC- minnesadressen på adressbussen , skickar en begäran till enheten om att läsa data från enhetens interna minne (buffert) . Enheten tar emot en begäran och vet inte ens om begäran kom från CPU:n eller från DMA-styrenheten. Enheten skickar nästa ord från sitt interna minne (buffert) till PC-minnet på adressen som finns på adressbussen . Enheten skickar sedan en signal till DMA-styrenheten som indikerar slutet på inspelningen. DMA-styrenheten ökar PC- minnesadressen och sätter den på adressbussen , minskar värdet på sin byte-räknare och skickar återigen en begäran om att läsa data från enhetens interna minne (buffert). Slingan upprepas tills räknarvärdet blir noll. Efter slutet av cykeln initierar enheten ett processoravbrott , vilket indikerar att dataöverföringen har slutförts.

En DMA-styrenhet som kan utföra flera operationer parallellt kallas en multikanal.

Bus mastering

MicroChannel -bussen , SBus , starkt påverkad av PCI och dess konceptuella derivator AGP och PCI-X , använder en annan implementering av DMA. Dessa bussar tillåter vilken enhet som helst att meddela behovet av att beslagta bussen, ett sådant behov tillgodoses av den så kallade arbitern vid första tillfället. En enhet som framgångsrikt fångar bussen ställer in adress- och styrsignalerna på bussen och utför under en tid samma ledande roll på bussen som CPU:n. CPU:ns åtkomst till bussen är då tillfälligt inaktiverad.

I en sådan DMA-implementering finns det ingen DMA-kontroller och inget DMA-kontrollerinmatningsnummer.

Vissa äldre PCI -enheter , nämligen ljudkortsimplementeringar av Sound Blaster -familjen , använde 8237 DMA-kontrollern från den ursprungliga IBM PC -arkitekturen . Denna användning är förvisso föråldrad för PCI , men har bibehållits för att säkerställa full programvara och drivrutinkompatibilitet med Sound Blaster -ljudkort för ISA-bussen .

Detta stöd kallas "Distributed DMA" (D-DMA) och är implementerat i hårdvara både i enheten och i logiken för PCI - ISA- bryggan, där logiken för 8237 DMA-styrenheten (original för IBM PC ) är finns även på PCI-system . Implementeringen använder två förfrågningar: den första begäran är från enheten till PCI-ISA-bryggan, den andra är från bryggan till PC - minnet .

Förutom de nämnda Sound Blaster- implementeringarna använder praktiskt taget inga PCI- enheter konceptet "DMA controller entry number", och det gör inte 8237 alls.

DMA och virtuellt minne , IOMMU och AGP GART

operativsystem med sökt virtuellt minne , som Windows och UNIX- familjen , kan en sammanhängande region av virtuella adresser implementeras av diskontinuerliga fysiska sidor.

Att utföra DMA för en sådan region är en stor utmaning. En svår uppgift är också att utföra DMA på det levererade minnet.

Lösningen på detta problem kräver identifiering av fysiska sidor som implementerar regionen, och deras blockering från leverans genom att komma åt det virtuella minnesundersystemet. Vidare blir det möjligt att hitta de fysiska adresserna till sidorna i regionen, som i det allmänna fallet inte är sammanhängande och bildar den så kallade "scatter-gather list" ( engelsk  scatter-gather list , SGL ).

Uppgiften att utföra DMA på en sådan lista kan lösas på något av följande sätt.

  1. Tilldelning av konsekutivt fysiskt minne i operativsystemets kärna och mellankopiering av all data till/från där (den så kallade "bounce buffer" - engelsk  bounce buffer ).

Stöds av alla ledande operativsystem . Aktivering av support på Windows kräver ett anrop med parametern inställd på . IoGetDmaAdapterDEVICE_DESCRIPTION::ScatterGatherFALSE

Brister:
  1. Dela upp en operation i deloperationer längs SGL -elementgränserna , med ett avbrott i slutet av varje operation.

Används i äldre 8-bitars SCSI - kontroller som levereras med skannrar av typen HP ScanJet .

Brister:
  1. Stöd för SGL av själva enheten, med kravet att kopiera SGL , omvandlat till ett enhetsspecifikt format, till enheten via flera åtkomster till enhetens register.
Brister:
  1. Stöd för SGL av enheten själv, med kravet att placera SGL , konverterad till ett enhetsspecifikt format, i en fysiskt sammanhängande region av huvudminnet.

Enheten läser SGL med samma busslåsande DMA -mekanism som den faktiska datan, och implementerar därigenom funktionaliteten hos en processor som läser och exekverar sitt eget "program" implementerat som en lista med SGL- deskriptorer . Denna arkitektur kallas "chain DMA" ( eng.  chain DMA ), implementerad i nästan all standardutrustning i en modern dator  - Intel IDE ( eng.  integrerad drivelektronik ) (i en primitiv form), USB UHCI , USB OHCI , 1394 OHCI , såväl som i de flesta PCI- , Ethernet- och SCSI- adaptrar (även den äldre AIC78xx ). Ett bra exempel på implementeringen av denna arkitektur i en mycket komplex och avancerad form ges i 1394 OHCI- hårdvaruspecifikationen . Enligt vissa rapporter användes denna arkitektur, kallad "kanalprogram", redan i IBM 360 , känd i Sovjetunionen som ES-datorer .

Brister:
  1. Stöd för SGL i interbusshårdvara, där representationen av en fysiskt burst buffert för enhetssidan verkar vara fysiskt sammanhängande.

Sådan utrustning kallas IOMMU ( input/output memory management unit ) .  Det implementerades både på datorer från Sun Microsystems för SBus -bussen och på datorer från DEC Alpha för PCI-bussen . Fram till nyligen implementerades det nästan aldrig i konventionella x86 /PCI- system, även om det för närvarande finns en trend att ändra denna situation, främst med målet att förbättra prestandan hos hypervisorer för virtuella maskiner . Alltid implementerad för AGP -bussen som kallas AGP GART för att underlätta GPU-slumpmässig åtkomst till texturer som finns i huvudminnet. Från enhetssidan standardiserades denna hårdvara av AGP- specifikationen , från mjukvarusidan fanns det ingen standardisering, och implementeringen berodde på tillverkaren av northbridge -chippet mellan AGP och minne (därav behovet av en " AGP- drivrutin ", till exempel för Intel- chips ). Anropsuppsättningen av kärnor i utvecklade operativsystem , såsom Windows , har alltid innehållit en arkitektonisk abstraktion av IOMMU ( och studsbuffert , uppfattad som ett slags IOMMU , stöder även dessa anrop ) , vilket tillåter samma enhetsdrivrutin att stödja den när den är ansluten genom olika IOMMUs . agp440.sys MapTransferGetScatterGatherList

Brister:

DMA och IDE/ATA, Ultra DMA

Den ursprungliga IBM PC /AT -hårddiskstyrenheten stödde inte DMA och krävde REP INSW/REP OUTSW-instruktioner för att skicka all disk I/O -data via port 0x1f0.

I början av 1990-talet föll MFM / RLL-enheter ur bruk ("dö ut"), ersattes av IDE- enheter , men registergränssnittet för programvaran till styrenheten har inte ändrats.

Den låga prestandan hos en sådan styrenhet har blivit ett allvarligt problem, särskilt på PCI- system . Förutom att kräva flera PCI-cykler för att överföra varannan byte med data, resulterade detta i att disk I/O laddade processorn .

För att lösa problemet har ett antal företag, inklusive Intel , utvecklat IDE-kontroller med DMA-stöd. Styrenheterna var och är fortfarande mjukvarukompatibla mellan olika tillverkare, även om kompatibilitet för alla Intel IDE/ATA/SATA nerifrån och upp mer eller mindre stöds.

En funktion för detta stöd är också användningen av nya IDE/ATA-protokollkommandon, vilket innebär kravet att stödja DMA inte bara av styrenheten utan också av själva hårddisken .

Runt 2000 utvecklades DMA-stöd över IDE/ATA-bussen för att öka bussens klockhastighet, vilket krävde en ny typ av kabel från styrenheten till enheten med dubbelt så många mindre ledare. Denna teknik kallades "Ultra DMA" ( UDMA ).

Många operativsystem krävde administratörsåtgärder för att använda IDE DMA. Så, till exempel, standard Linux-kärnor fram till omkring 2004 inte hade sådant stöd, det krävdes att bygga om kärnan med en redigerad konfigurationsfil.

I Windows OS- familjen dök stöd för IDE DMA först endast upp för Intel i servicepack för Windows NT 4 och krävde manuell redigering av registret på de flesta system för att aktivera det.

I Windows 2000 försvann detta krav, men det fanns ett krav på att även icke-startbara diskar skulle listas och ställas in på DMA i BIOS . Dessa inställningar blev synliga för OS -kärnan genom ACPI -teknik , och operativsystemet tillät inte att DMA aktiverades för en disk som inte fanns med i BIOS -disklistan . Som jämförelse stödde Windows NT 4 både anpassad diskstorlek och DMA utan att lista disken i BIOS .

Linux kanhdparm ett kommando (se nedan ) användas för att manuellt aktivera eller inaktivera IDE DMA . Moderna kärnversioner aktiverar automatiskt DMA-läge, vilket kan ses i felsökningsmeddelanden (rader som "ata1.00: konfigurerad för UDMA/133" eller "hda: UDMA/33-läge valt").

ATA Protocol Ultra DMA-lägen för Linux OS

hdparm -i /dev/sda
M Byte / s
Läge 0 16.7 UDMA16
Läge 1 25,0 UDMA25
Läge 2 33.3 UDMA33
Läge 3 44,4 UDMA44
Läge 4 66,7 UDMA66
Läge 5 100,0 UDMA100
Läge 6 133,3 UDMA133

Se även

Anteckningar

  1. z/OS Communications Server | Direkt fjärrminnesåtkomst över konvergerat Ethernet (senast uppdaterad i V2R1) . Hämtad 3 augusti 2019. Arkiverad från originalet 3 augusti 2019.

Länkar