|



u à

     
 
      
u  


  

   

  
u 
  !

 "#à
 
  $

%   

u #!      ! %
!!
&'à(
u !!   
     

 
  
!   %)
u Usually we don't notice any performance problems)

u è
  


 |





 

 
 




  
 




  
 



 

     







 
 


 





 |



‡ E.g, in Linux OS if you have more data than physical
memory, the system store it temporarily on the hard disk if
not needed at the moment.
‡ Process of moving data to and from the disk is called
M
.
 àain Idea

System Cache
Is cached by
àain àemory
Is cached by
Virtual àemory
(residing on disk)

‡ All memory transfers are only between consecutive levels

(e.g. Và to main memory, main memory to cache).
 Cache vs. Và
‡ Concept behind Và is almost identical to concept behind
cache.
‡ But different terminology!
± Cache: Block Và: Page
± Cache: Cache àiss Và: Page Fault
‡ Caches implemented completely in hardware.
‡ Và implemented in software, with hardware support from
CPU.
‡ Cache speeds up main memory access, while main memory
speeds up Và access.
 Virtual àemory Design
‡ àain àemory at Virtual àemory are both divided into
fixed size pages.
± Page size is typically about 16KB to 32KB.
± Large page sizes are needed as these can be more efficiently
transferred between main memory and virtual memory.
± Size of M


 ALWAYS equal to size of  



 


.
‡ Pages in main memory are given M



 M, while
pages in virtual memory are given  



 M.
± I.e. First 32KB of main memory is physical page 0, 2nd 32KB is
physical page 1 etc.
± First 32KB of virtual memory is virtual page 0, etc.
 Virtual àemory Design
‡ In cache, we can search through all the blocks until
we find the data for the address we want.
± This is because the number of blocks is small.
‡ This is extremely impractical for virtual memory!
± The number of Và pages is in the tens of thousands!
 Solution
‡ Use a look up table.
‡ The addresses generated by the CPU is called the  

 MM.
‡ The virtual address is divided into a page offset and a
virtual page number:

Virtual Page Number Page Offset

‡ The virtual page number indicates which page of

virtual memory the data that the CPU needs is in.
 Solution«cont

‡ The data must also be in physical memory before it can be

used by the CPU!
‡ Need a way to translate between the virtual page number
where the data is in Và, to the page number of the physical
page where the data is in physical memory.
‡ To do this, use Virtual Page Table.
± î


  resides in main memory.
± One entry per virtual page. Can get VERY large as the number of
virtual pages can be in the tens of thousands.
 Virtual Page Table
1. Gives the physical page (frame) # of a virtual page, if that page is
in memory.
2. Gives location on disk if virtual page is not yet in main memory.

frame0
page0 frame1
page1 frame2
page2 frame3
page3 Physical àemory
page4
page5
Virtual àemory Table Và (on Disk Space)
 Page Table Contents
‡ The page table also contains a Valid Bit (V) 





 



M



  (V=1) or still on
disk (V=0).
page0 1 2
page1 0 (2,1,7)
page2 1 0
page3 1 1
page4 0 (7,2,9)
page5 1 3

‡ If a page is in physical memory (V=1), then the page

table gives the Frame #.
‡ Otherwise it gives the location of the page on disk , in
the form (side#, track#, block#).
 Accessing Data
‡ To retrieve data:
1. Extract the Virtual Page Number from the Virtual
Address

Virtual Page Number (e.g. 02) Page Offset

Virtual Page Number (e.g. 02) Page Offset

 Accessing Data
2. Use the page to look up the page table. If V=1, get the frame from
the page table:

page0 1 2
page1 0 (2,1,7)
page = 2
page2 1 0 frame=0
page3 1 1
page4 0 (7,2,9)
page5 1 3

Here virtual page#2 mapped to frame#0.

 Accessing Data
3. Combine the frame found with the page offset to form the physical
memory address:

Phyiscal Page Number 0 Page Offset

Physical Page Number 0 Page Offset

Physical Address
 Accessing Data
4. Access main memory using the physical address.
± A page consists of many bytes (e.g. 32KB)
± The page offset tells us exactly which byte of these 32KB we are
accessing.
‡ Similar to the idea of block offset and byte offset in caches
 Page Fault
‡ ½
 
 





  
1. In this case, V=0, and the page table contains the disk
address of the page (e.g. page1 in the previous example is
still at side 2, track 1, block 7 (2,1,7) of the disk.
2. Find a free physical page
- if none are available, apply a replacement policy (e.g. LRU) to
find one.
3. Load the virtual page into the physical page.
- Set the V flag, and update the page table to show which
physical page the virtual page has gone to.
Behavior of Page Replacement Algorithms
Example: 3
 M


M 

M


M
3


u
M!
"#
$
%&!M#

load 00100 0 00 C-Miss P-Fault load 32

load 00101 0 00 C-Miss P- Hit! load 40
Index Valid Tag Xata
0 NYY 00100
00101 Memory[000100
Memory[000101 00 00]
00]
1 N

Virtual Page Number Page offset

001
001 00000
01000 Memory
Page Index Valid Frame number
0 N
1 NY 111 Xisk
... N
 r
 
Suppose we have
32 bit  


 MM (232 bytes)
4096 bytes 

 (212 bytes)
4 bytes 



 
  (22 bytes)

½
 




3 3
'  
 
   M ü 3 ü 3 3
 M
3
3
3 33
() 
 
  ü 3   M 3 M ü 3 M ü  à

4 àegabytes just for page tables!! Too Big

 Writing to Và
‡ Writes to Virtual àemory is m
m done on a

m
 basis.
‡ To support write-back, the page-table must be
augmented with a   (D).
‡ This bit is set if the page is updated in physical
memory.
 Writing to Và
D V frame or disk location
page0 0 1 2
page1 0 0 (2,1,7)
page2 1
1 1
1 0
page3 0 1 1
page4 0 0 (7,2,9)
page5 0 1 3

‡ Here virtual 
"3 was updated in physical 
"


"
.
‡ If 
"
is ever replaced, its contents must be written back to disk
to update 
"3

"3.
 Translation Look-aside Buffer
‡ An access to virtual memory requires 2 main memory accesses at best.
± One access to read the page table, another to read the data.
‡ Remember from the Cache section that main memory is M 
‡ Fortunately, page table accesses themselves tend to display both
temporal and spatial locality!
± Temporal Locality: Accesses to the different words in the same page will cause
access to same entry in page table!
± Spatial Locality: Sequential access of data from one virtual page into the next
will cause consecutive accesses to page table entries.
‡ Initially I am at page0, and I access Page Table entry for page0. As I move into
page1, I will access Page Table entry for page1, which is next to page table entry for
page0!
 Translation Look-aside Buffer
‡ Solution:
± Implement a cache for the page table! This cache is called the
translation look-aside buffer, or TLB.
± The TLB is 

 from the caches we were looking at earlier.
‡ Those caches cached data from main memory.
‡ The TLB caches page table entries! Different!
± TLB is small (about 8 to 10 blocks), and is implemented as a fully
associative cache.
 Translation Look-aside Buffer

‡ Fully Associative
± New page table entries go into the next free TLB block,
or a block is replaced if there are none.
‡ Note that only page table entries with V=1 are
written to the TLB!
‡ The page table entries already in the TLB are not
usually updated, so no need to consider write-
through or write-back
± Exceptional cases: page aliasing, where more than 1
page can refer to the same Physical Page.
 Translation Look-aside Buffer
‡ The tags used in the TLB is the virtual page number of a
virtual address.
‡ All TLB blocks are searched for the page. If found, we have
a TLB hit and the physical page number is read from the
TLB. This is joined with the page offset to form the
physical address.
‡ If not found, we have a TLB miss. Then we must go to the
page table in main memory to get the page table entry there.
Write this entry to TLB.
 Translation Look-aside Buffer
‡ Complication
± If we have a TLB miss and go to main memory to get the page
table entry, it is possible that this entry has a V of 0 - page fault.
± In this case we must remedy the page fault first, update the page
table entry in main memory, and then copy the page table entry
into TLB. The tag portion of TLB is updated to the page of the
virtual address.
‡ Note that the TLB must also have a valid bit V to indicate if
the TLB entry is valid (see cache section for more details on
the V bit.)
 Integration Cache, àain àemory and
Virtual àemory
‡ Suppose a Virtual Address | is generated by the CPU
(either from PC for instructions, or from ALU for
and 

instructions).
1. Perform address translation from Virtual Address to Physical
Address
(a) Look up TLB or page table (see previous slides). Remedy page
fault if necessary (again, see previous slides).
2. Use the physical address to access the cache (see cache notes).
3. If cache hit, read the data (or instruction) from the cache.
4. If cache miss, read the data from main memory.
Use of a Translation Lookaside Buffer
 Integration Cache, àain àemory and
Virtual àemory
‡ Note that a page-fault in Và will necessarily cause a cache
miss later on (since the data wasn¶t in physical memory, it
cannot possibly be in cache!)
‡ Can optimize algorithm in event of page fault:
1. Remedy the page fault.
2. Copy the data being accessed directly to cache.
3. Restart previous algorithm at step 3.
‡ This optimization eliminates 1 unnecessary cache access
that would definitely miss.
 Page Table Size
‡ A Virtual àemory System was implemented for a àIPS
workstation with 128àB of main memory. The Virtual
àemory size is 1GB, and each page is 32KB. Calculate the
size of the page table.
 Page Table Size

‡ Previous calculation shows that page tables are

huge!
‡ These are sitting in precious main memory space.
‡ Solutions:
± Use inverted page tables
‡ Instead of indexing virtual pages, index physical pages.
‡ Page table will provide virtual page numbers instead.
‡ Search page table for the page of address virtual address |. If
the page is found in entry 25, then the data can be found in
physical page 25.
± Have portions of page table in virtual memory.
‡ Slow, complex
 Finer Points of Và
‡ Và is a collaboration between hardware and OS
± Hardware:
‡ TLB
‡ Page Table Register
± Indicates where the page table is in main memory
‡ àemory Protection
± Certain virtual pages are allocated to processes running in memory.
± If one process tries to access the virtual page of another process without
permission, hardware will generate exception.
± This gives the famous ³General Protection Fault´ of windoze and the
³Segmentation Fault´ of Unix.
 Finer Points of Và
± Hardware
‡ Does address translations etc.
± Operating System
‡ Actually implements the virtual memory system.
± Does reads and writes to/from disk
± Creates the page table in memory, sets the Page Table Register to point to the
start of the page table.
± Remedies page faults,updates the page table.
± Remedies Và violations
» Windows: Pops up blue screen of death, dies messily. Sometimes thrashes
your hard-disk.
» Unix: Gives ³Segmentation Fault´. Kills offending process and continues
working.
 Finer Points of Và

‡ Where is the Virtual àemory located on disk?

± Virtual memory is normally implemented as a very large file,
created by the OS. E.g. in Windows NT, the virtual memory file is
called swapfile.sys
‡ Insecure. Sometimes sensitive info gets written to swapfile.sys, and you can
later retrieve the sensitive info.
‡ In Unix, implemented as a partition on the disk that cannot be read except by
the OS. Unix good. Windows bad.
± Whenever virtual memory is read or written to, the OS actually
reads or writes from/to this file.
‡ Virtual àemory is NOT the other files on your disk (e.g. your JAVA
assignment)
 Page Tables
       !    
  

*
   !

  

 '   +  .   -  /   ' &  '  '   '   ' '  ' +  .  -      '  +

*
   !                   

+ '

*  !

  
  !           

       !

'-
   +          
   ,
      
     

 .  -  / ' &   '    '    '    ' '  ' + . -      '  +

  
  !                   

  
  !  

   
 àaking Address Translation Fast
‡ A cache for address translations: translation lookaside


buffer
|
 !
 


| !


   
 !
    




    
 !     





   !
   
 !

| !
   
 $       


 $    

 TLBs and caches
|
  !   

    

 
    ´

 

  
   
 !   

 ´
 
 

      
       
      ´ 

 

 
    
 
  
   
 
   
 ´      
    
  
  !!   
            

     
   

 !