Top Banner
Lecture 8: Memory Management CSE 120: Principles of Opera>ng Systems UC San Diego: Summer Session I, 2009 Frank Uyeda
42

Lecture 8: Memory Management - UC San Diego

Feb 11, 2022

Download

Documents

dariahiddleston
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Lecture 8: Memory Management - UC San Diego

Lecture8:MemoryManagementCSE120:PrinciplesofOpera>ngSystems

UCSanDiego:SummerSessionI,2009FrankUyeda

Page 2: Lecture 8: Memory Management - UC San Diego

Announcements

•  PeerWiseques>onsduetomorrow.•  Project2isdueonFriday.– MilestoneonTuesdaynight.Tonight.

•  Homework3isduenextMonday.

2

Page 3: Lecture 8: Memory Management - UC San Diego

PeerWise

•  Abaseregistercontains:– Thefirstavailablephysicalmemoryaddressforthesystem

– Thebeginningphysicalmemoryaddressofaprocess’saddressspace

– Thebase(i.e.base2forbinary,etc)thatisusedfordeterminingpagesizes

– Theminimumsizeofphysicalmemorythatwillbeassignedtoeachprocess

3

Page 4: Lecture 8: Memory Management - UC San Diego

PeerWise

•  Ifthebaseregisterholds640000andthelimitregisteris200000,thenwhatrangeofaddressescantheprogramlegallyaccess?– 440000through640000– 200000through640000– 0through200000– 640000through840000

4

Page 5: Lecture 8: Memory Management - UC San Diego

GoalsforToday

•  UnderstandPaging– Addresstransla>on– PageTables

•  UnderstandSegmenta>on– Howitcombinesfeaturesofothertechniques

5

Page 6: Lecture 8: Memory Management - UC San Diego

Recap:VirtualMemory

•  MemoryManagementUnit(MMU)–  Hardwareunitthattranslatesavirtualaddresstoaphysicaladdress

–  EachmemoryreferenceispassedthroughtheMMU

–  Translateavirtualaddresstoaphysicaladdress

•  Transla>onLookasideBuffer(TLB)–  Essen>allyacachefortheMMU’svirtual‐to‐physicaltransla>onstable

–  Notneededforcorrectnessbutsourceofsignificantperformancegain

6

CPUTransla>on

TableMMU

Memory

VirtualAddress

PhysicalAddress

TLB

Page 7: Lecture 8: Memory Management - UC San Diego

Recap:Paging

•  Pagingsolvestheexternalfragmenta>onproblembyusingfixedsizedunitsinbothphysicalandvirtualmemory

7

Page1

Page2

Page3

Page4

Page5

PhysicalMemory

Page1

Page2

PageN

VirtualMemory

…..

Page 8: Lecture 8: Memory Management - UC San Diego

MemoryManagementinNachos

8

Page1

Page2

Page3

PageP

PhysicalMemory

Code

Code

VirtualMemory

…..

0x…..

0x00000000 0x00000000

0x00040000

0x00000400

...

PageN

..

Stack

Data

Page 9: Lecture 8: Memory Management - UC San Diego

MemoryManagementinNachos

9

Page1

Page2

Page3

PageP

PhysicalMemory

Code

Code

VirtualMemory

…..

0x…..

0x00000000 0x00000000

0x00040000

0x00000400

...

PageN

..

Stack

Data

•  Whatifcodesec>onisn’tamul>pleofpagesize?•  Whatif0x…..islargerthanphysicalmemory?•  Whatif0x…..issmallerthanphysicalmemory?

Page 10: Lecture 8: Memory Management - UC San Diego

MemoryManagementinNachos

•  Howdoweknowhowlargeaprogramis?–  Alotisdoneforyouinuserprog/UserProcess.java

•  Yourapplica>onswillbewrihenin“C”•  Your“C”programscompileinto.cofffiles

•  Coff.javaandCoffSec>on.javaareprovidedtopar>>onthecofffile

–  Ifnotenoughphysicalmemory,exec()returnserror•  Nachosexec()isdifferentfromUnixexec()!!!!!

•  VirtualMemorymapsexactlytoPhysicalMemory?–  Whoneedsapagetable,TLBorMMU?–  Whataretheimplica>onsforthisintermsof

mul>programming?

10

Page 11: Lecture 8: Memory Management - UC San Diego

Project2:Mul>programming

•  Needtosupportformul>progamming– Programscoexistonphysicalmemory

– Howdowedothis?

11

P1

P2

P3

P4

P5

PhysicalMemory

BaseRegisterP4’sBase

VirtualAddressOffset +

P1

P2

P3

PhysicalMemoryBaseRegisterP4’sBase

VirtualAddressOffset +

LimitRegisterP3’sBase

< Yes?

No?

Protec>onFaultWouldFixedPar>>onswork?WouldVariablePar>>onswork?

Page 12: Lecture 8: Memory Management - UC San Diego

Paging

1212

Page1

Page2

Page3

PageP

PhysicalMemoryPage1

Page2

Process1’sVAS

…..

0x00000000

0x00040000

0x00000400

...

PageN

..

PageM

Page3

…..

Page1

Page2

Process2’sVAS

PageQ

Page3

MMU

TLB

PageTable

Page 13: Lecture 8: Memory Management - UC San Diego

MMUandTLB

•  MemoryManagementUnit(MMU)–  Hardwareunitthattranslatesavirtualaddresstoaphysicaladdress

–  EachmemoryreferenceispassedthroughtheMMU

–  Translateavirtualaddresstoaphysicaladdress

•  Transla>onLookasideBuffer(TLB)–  Essen>allyacachefortheMMU’svirtual‐to‐physicaltransla>onstable

–  Notneededforcorrectnessbutsourceofsignificantperformancegain

13

CPUTransla>on

TableMMU

Memory

VirtualAddress

PhysicalAddress

TLB

Page 14: Lecture 8: Memory Management - UC San Diego

Paging:Transla>ons

•  Transla>ngaddresses–  Virtualaddresshastwoparts:virtualpagenumberandoffset

–  Virtualpagenumber(VPN)isanindexintoapagetable–  Pagetabledeterminespageframenumber(PFN)

–  PhysicaladdressisPFN::offset

14

0xBAADF00D=offsetvirtualpagenumber

0xBAADF 0x00D

Transla>onTable

pagetable

0xBAADF 0x900DFphysicalpagenumber(pageframenumber)

virtualpagenumber

virtualaddress

Page 15: Lecture 8: Memory Management - UC San Diego

PageTableEntries(PTEs)

•  Pagetableentriescontrolmapping–  TheModifybitsayswhetherornotthepagehasbeenwrihen

•  Itissetwhenawritetothepageoccurs–  TheReferencebitsayswhetherthepagehasbeenaccessed

•  Itissetwhenareadorwritetothepageoccurs–  TheValidbitsayswhetherornotthePTEcanbeused

•  Itischeckedeach>methevirtualaddressisused–  TheProtec>onbitssaywhatopera>onsareallowedonpage

•  Read,write,execute–  Thepageframenumber(PFN)determinesphysicalpage

•  Note:whenyoudoexercisesinexamsorhw,we’llopentellyoutoignorecoun>ngM,R,V,Protbitswhencalcula>ngsizeofstructures

15

PageFrameNumberProtVRM

1 1 1 2 20

Page 16: Lecture 8: Memory Management - UC San Diego

PagingExampleRevisited

16

Page1

Page2

Page3

PageN

PhysicalMemory…..

Pageframe Offset

PhysicalAddress

Pagenumber Offset

VirtualAddress

Pagetableentry

PageTable

0xBAADF00D

0xBAADF 0xF00D

0xF00D0x900DF

0x900DF00D

0xFFFFFFFF

0x00000000

Pagenumber

PageFrameNumberProtVRM

Page 17: Lecture 8: Memory Management - UC San Diego

Paging

1717

Page1

Page2

Page3

PageP

PhysicalMemoryPage1

Page2

Process1’sVAS

…..

0x00000000

0x00040000

0x00000400

...

PageN

..

PageM

Page3

…..

Page1

Page2

Process2’sVAS

PageQ

Page3

MMU

TLB

PageTable

V PageFrame

1 0x04

1 0x01

1 0x05

1 0x07

V PageFrame

1 0x04

1 0x01

1 0x05

1 0x07

Page 18: Lecture 8: Memory Management - UC San Diego

Example

•  AssumeweareusingPagingand:– Memoryaccess=5us–  TLBsearch=500ns

•  Whatistheavg.memoryaccess>mewithouttheTLB?•  Whatistheavg.memoryaccess>mewith50%TLBhitrate?•  Whatistheavg.memoryaccess>mewith90%TLBhitrate?

18

CPUTransla>on

TableMMU

Memory

VirtualAddress

PhysicalAddress

TLB

Page 19: Lecture 8: Memory Management - UC San Diego

PagingAdvantages

•  Easytoallocatememory– Memorycomesfromafreelistoffixed‐sizechunks–  Alloca>ngapageisjustremovingitfromthelist

–  Externalfragmenta>onisnotaproblem

•  Easytoswapoutchunksofaprogram–  Allchunksarethesamesize–  Pagesareaconvenientmul>pleofthediskblocksize

–  Howdoweknowifapageisinmemoryornot?

19

Page 20: Lecture 8: Memory Management - UC San Diego

PagingLimita>ons

•  Cans>llhaveinternalfragmenta>on–  Processmaynotusememoryinmul>plesofpages

•  Memoryreferenceoverhead–  2referencesperaddresslookup(pagetable,thenmemory)

–  Solu>on–useahardwarecacheoflookups(TLB)•  Memoryrequiredtoholdpagetablecanbesignificant

–  NeedonePTEperpage–  32‐bitaddressspacew/4KBpages=upto____PTEs–  4bytes/PTE=_____MBpagetable–  25processes=______MBjustforpagetables!–  Solu>on:pagethepagetables(morelater)

20

Page 21: Lecture 8: Memory Management - UC San Diego

Paging:LinearAddressSpace

Stack

Heap

DataSegment

TextSegment

21

0x00…….(Star>ngAddress)

0xFFF…..(EndingAddress)

Page 22: Lecture 8: Memory Management - UC San Diego

Segmenta>on:Mul>pleAddressSpaces

22

Heap

Text

Data

Stack

Page 23: Lecture 8: Memory Management - UC San Diego

Segmenta>on

23

PhysicalMemorySegmentTable

limit baseVirtualAddress

Segment# Offset

< +Yes?

No?

Protec>onFault

Page 24: Lecture 8: Memory Management - UC San Diego

Segmenta>on

•  Segmenta>onisatechniquethatpar>>onsmemoryintologicallyrelateddataunits– Module,procedure,stack,data,file,etc.–  Virtualaddressesbecome<segment#,offset>–  Unitsofmemoryfromuser’sperspec>ve

•  Naturalextensionofvariable‐sizedpar>>ons–  Variable‐sizedpar>>ons=1segment/process–  Segmenta>on=manysegments/process

•  Hardwaresupport– Mul>plebase/limitpairs,onepersegment(segmenttable)–  Segmentsnamedby#,usedtoindexintotable

24

Page 25: Lecture 8: Memory Management - UC San Diego

SegmentTable

•  Extensions–  Canhaveonesegmenttableperprocess

•  Segment#sarethenprocess‐rela>ve(whydothis?)–  Caneasilysharememory

•  Putsametransla>onintobase/limitpair•  Cansharewithdifferentprotec>ons(samebase/limit,diffprot)•  Whyisthisdifferentfrompurepaging?

–  Candefineprotec>onbysegment•  Problems

–  Cross‐segmentaddresses•  Segmentsneedtohavesame#sforpointerstothemtobesharedamongprocesses

–  Largesegmenttables•  Keepinmainmemory,usehardwarecacheforspeed

25

Page 26: Lecture 8: Memory Management - UC San Diego

Segmenta>onExample

26

ExternalFragmenta>oninSegmenta>onNote:ImagecourtesyofTanenbaum,MOS3/e

Page 27: Lecture 8: Memory Management - UC San Diego

PagingvsSegmenta>onConsidera4on Paging Segmenta4on

Needtheprogrammerbeawarethatthistechniqueisbeingused?

Howmanylinearaddressspacesarethere?

Canthetotaladdressspaceexceedthesizeofphysicalmemory?

Canproceduresanddatabedis>nguishedandseparatelyprotected?

Issharingofproceduresbetweenusersfacilitated?

27Note:ImageadaptedfromTanenbaum,MOS3/e

Page 28: Lecture 8: Memory Management - UC San Diego

Segmenta>onandPaging

•  Cancombinesegmenta>onandpaging–  Thex86supportssegmentsandpaging

•  Usesegmentstomanagelogicallyrelatedunits– Module,procedure,stack,file,data,etc.–  Segmentsvaryinsize,butusuallylarge(mul>plepages)

•  Usepagestopar>>onsegmentsintofixedsizedchunks– Makessegmentseasiertomanagewithinphysicalmemory

•  Segmentsbecome“pageable”–ratherthanmovingsegmentsintoandoutofmemory,justmovepagepor>onsofsegment

–  Needtoallocatepagetableentriesonlyforthosepiecesofthesegmentsthathavethemselvesbeenallocated

•  Tendstobecomplex…

28

Page 29: Lecture 8: Memory Management - UC San Diego

VirtualMemorySummary

•  Virtualmemory–  Processesusevirtualaddresses–  OS+hardwaretranslatesvirtualaddressesintophysicaladdresses

•  Varioustechniques–  Fixedpar>>ons–easytouse,butinternalfragmenta>on–  Variablepar>>ons–moreefficient,butexternalfragmenta>on

–  Paging–usesmall,fixedsizechunks,efficientforOS–  Segmenta>on–manageinchunksfromuser’sperspec>ve–  Combinepagingandsegmenta>ontogetbenefitsofboth

29

Page 30: Lecture 8: Memory Management - UC San Diego

ManagingPageTables

•  Wecomputedthesizeofthepagetablefora32‐bitaddressspacewith4Kpagestobe___MB–  Thisisfartoomuchoverheadforeachprocess

•  Howcanwereducethisoverhead?–  Observa>on:Onlyneedtomapthepor>onoftheaddressspaceactuallybeingused(>nyfrac>onofen>readdressspace)

•  Howdoweonlymapwhatisbeingused?–  Candynamicallyextendpagetable…–  Doesnotworkifaddressspaceissparse(internalfragmenta>on)

•  Useanotherlevelofindirec>on:mul>‐levelpagetables

30

Page 31: Lecture 8: Memory Management - UC San Diego

ManagingPageTables

•  Wecomputedthesizeofthepagetablefora32‐bitaddressspacewith4Kpagestobe100MB–  Thisisfartoomuchoverheadforeachprocess

•  Howcanwereducethisoverhead?–  Observa>on:Onlyneedtomapthepor>onoftheaddressspaceactuallybeingused(>nyfrac>onofen>readdressspace)

•  Howdoweonlymapwhatisbeingused?–  Candynamicallyextendpagetable…–  Doesnotworkifaddressspaceissparse(internalfragmenta>on)

•  Useanotherlevelofindirec>on:mul>‐levelpagetables

31

Page 32: Lecture 8: Memory Management - UC San Diego

One‐LevelPageTable

32

Page1

Page2

Page3

PageN

PhysicalMemory…..

Pageframe Offset

PhysicalAddress

Pagenumber Offset

VirtualAddress

Pageframe(PTE)

PageTable

0xFFFFFFFF

0x00000000

Page 33: Lecture 8: Memory Management - UC San Diego

Two‐LevelPageTable

33

Page1

Page2

Page3

PageN

PhysicalMemory…..

Pageframe Offset

PhysicalAddress

Secondary Offset

VirtualAddress

SecondaryPageTable(s)

0xFFFFFFFF

0x00000000

Master

Pagetableentry

MasterPageTable

Pageframe(PTE)Pageframe(PTE)

Page 34: Lecture 8: Memory Management - UC San Diego

Two‐LevelPageTables

•  Originally,virtualaddresses(VAs)hadtwoparts–  Pagenumber(whichmappedtoframe)andanoffset

•  NowVAshavethreeparts:– Masterpagenumber,secondarypagenumber,andoffset

•  MasterpagetablemapsVAstosecondarypagetable– We’dlikeamanageablemasterpagesize

•  Secondarytablemapspagenumbertophysicalpage–  Determineswhichphysicalframetheaddressresidesin

•  Offsetindicateswhichbyteinphysicalpage–  Finalsystempage/framesizeiss>llthesame,sooffsetlengthstaysthesame

34

Page 35: Lecture 8: Memory Management - UC San Diego

Two‐LevelPageTableExample

35

Page1

Page2

Page3

PageN

PhysicalMemory…..

Pageframe Offset

PhysicalAddress

Secondary Offset

VirtualAddress

SecondaryPageTable(s)

0xFFFFFFFF

0x00000000

Master

Pagetableentry

MasterPageTable

Pageframe(PTE)Pageframe(PTE)

Example:4KBpages,4BPTEs(32‐bitRAM),andsplitremainingbitsevenlyamongmasterandsecondary

121010

1Kentries 1Kentries

Page 36: Lecture 8: Memory Management - UC San Diego

WheredoPageTablesLive?

•  Physicalmemory–  Easytoaddress,notransla>onrequired–  But,allocatedpagetablesconsumememoryforlife>meofVas

•  Virtualmemory(OSvirtualaddressspace)–  Cold(unused)pagetablepagescanbepagedouttodisk–  But,addressingpagetablesrequirestransla>on–  Howdowestoprecursion–  Donotpagetheouterpagetable(aninstanceofpagepinning

orwiring)•  Ifwe’regoingtopagethepagetables,mightaswellpage

theen>reOSaddressspace,too–  Needtowirespecialcodeanddata(fault,interrupthandlers)

36

Page 37: Lecture 8: Memory Management - UC San Diego

EfficientTransla>ons

•  Ouroriginalpagetableschemealreadydoubledthecostofdoingmemorylookups–  Onelookupintothepagetable,anothertofetchthedata

•  Nowtwo‐levelpagetablestriplethecost!–  Twolookupsintothepagetables,athirdtofetchthedata–  Andthisassumesthepagetableisinmemory

•  Howcanweusepagingbutalsohavelookupscostaboutthesameasfetchingfrommemory?–  Cachetransla>onsinhardware–  Transla>onLookasideBuffer(TLB)–  TLBmanagedbyMemoryManagementUnit(MMU)

37

Page 38: Lecture 8: Memory Management - UC San Diego

TLBs

•  Transla>onLookasideBuffers–  Translatevirtualpage#sintoPTEs(notphysicaladdresses)–  Canbedoneinasinglemachinecycle

•  TLBsimplementedinhardware–  Fullyassocia>vecache(allentrieslookedupinparallel)–  Cachetagsarevirtualpagenumbers–  CachevaluesarePTEs(entriesfrompagetables)–  WithPTE+offset,candirectlycalculatephysicaladdress

•  TLBsexploitlocality–  Processesonlyuseahandfulofpagesata>me

•  16‐48entries/pages(64‐192K)•  Onlyneedthosepagestobe“mapped”

–  Hitratesarethereforeveryimportant

38

Page 39: Lecture 8: Memory Management - UC San Diego

LoadingTLBs

•  Mostaddresstransla>onsarehandledusingtheTLB–  >99%oftransla>ons,buttherearemisses(TLBmiss)…

•  Whopacestransla>onsintotheTLB(loadstheTLB)?–  SopwareloadedTLB(OS)

•  TLBfaultstotheOS,OSfindsappropriatePTE,loadsitintoTLB•  Mustbefast(buts>ll20‐200cycles)•  CPUISAhasinstruc>onsformanipula>ngTLB•  TablescanbeinanyformatconvenientforOS(flexible)

–  Hardware(MemoryManagementUnit)•  Mustknowwherepagetablesareinmainmemory•  OSmaintainstables,HWaccessesthemdirectly•  TableshavetobeinHW‐definedformat(inflexible)

39

Page 40: Lecture 8: Memory Management - UC San Diego

ManagingTLBs

•  OSensuresthatTLBandpagetablesareconsistent– WhenIchangestheprotec>onbitsofaPTE,itneedstoinvalidatethePTEifitisintheTLBalso

•  ReloadTLBonaprocesscontextswitch–  Invalidateallentries– Why?Whatisonewaytofixit?

•  WhentheTLBmissesandanewPTEhastobeloaded,acachedPTEmustbeevicted–  ChoosingaPTEtoevictiscalledtheTLBreplacementpolicy

–  Implementedinhardware,opensimple(e.g.,Last‐Not‐Used)

40

Page 41: Lecture 8: Memory Management - UC San Diego

Summary

•  Segmenta>on–  Observa>on:Userapplica>onsgrouprelateddata–  Idea:Setvirtual‐>physicalmappingtomirrorapplica>onorganiza>on.Assignprivilegespersegment.

•  PageTablemanagement–  Observa>on:Per‐processpagetablescanbeverylarge–  Idea:Pagethepagetables,usemul>‐levelpagetables

•  Efficienttransla>ons–  Observa>on:Mul>‐levelpagetablesandotherpagefaultscanmakememorylookupsslow

–  Idea:CachelookupsinhardwareTLB

41

Page 42: Lecture 8: Memory Management - UC San Diego

NextTime

•  ReadChapter9•  Peerwiseques>onsduetomorrowatmidnight.

•  CheckWebsiteforcourseannouncements–  hhp://www.cs.ucsd.edu/classes/su09/cse120

42