CS4500/5500 Opera"ng Systems Basic Memory Management

harpywarrenSoftware and s/w Development

Dec 14, 2013 (3 years and 5 months ago)

211 views

Ref.  MOS3E,  
OS@Aus0n
,  Columbia,  Rochester  
CS4500/5500  
CS4500/5500  
Opera-ng  Systems
 
Basic  Memory  Management
 
 
Jia
 
Rao
 
Department  of  Computer  Science  
hCp://www.cs.uccs.edu/~jrao/CS4500_5500/fall2013  
UC.  Colorado  Springs  
Recap  of  Previous  Classes

Ref.  MOS3E,  
OS@Aus0n
,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  


Mul0programming  
o

Requires  mul0ple  programs  to  run  at  the  “same”  0me  
o

Programs  must  be  brought  into  memory  and  placed  within  a  
process  for  it  to  be  run  
o

How  to  manage  the  memory  of  these  processes?  
o

What  if  the  memory  footprint  of  the  processes  is  larger  than  
the  physical  memory?  
Memory  Management  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  


Ideally  programmers  want  memory  that  is  
o

large  
o

fast  
o

non  vola0le  
o

and  cheap  


Memory  hierarchy    
o

small  amount  of  fast,  expensive  memory  –  cache    
o

some  medium-­‐speed,  medium  price  main  memory  
o

gigabytes  of  slow,  cheap  disk  storage  


Memory  management  tasks  
o

Allocate  and  de-­‐allocate  memory  for  processes  
o

Keep  track  of  used  memory  and  by  whom  
o

Address  transla0on  and  protec0on  
Memory  is  cheap  and  large  in  today

s  
desktop,  why  memory    
management  s-ll  important?  
No  Memory  Abstrac-on  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  
Three  simple  ways  of  organizing  memory.  (a)  early  mainframes.  (b)  Handheld  
and  embedded  systems.  (c)  early  PC.  


Mono-­‐programming:  One  program  at  a  0me,  sharing  
memory  with  OS  


Need  for  mul0-­‐programming:  1.  Use  mul0ple  CPUs.  2.  Overlapping  I/O  and  
CPU  
Mul-programming  with  Fixed  Par--ons  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  


Fixed-­‐size  memory  par00ons,  without  swapping  or  paging
 
o

Separate  input  queues  for  each  par00on  
o

Single  input  queue  
o

Various  job  schedulers  
What  are  the  disadvantages?  
Mul-programming  w  and  w/o  Swapping  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  


Swapping  
o

One  program  at  one  0me  
o

Save  the  en0re  memory  of  the  previous  program  to  disk  
o

No  address  transla0on  is  required  and  no  protec0on  is  needed  


w/o  swapping  
o

Memory  is  divided  into  blocks  
o

Each  block  is  assigned  a  protec0on  key  
o

Programs  work  on  absolute  memory,  no  address  transla0on  
o

Protec0on  is  enforced  by  trapping  unauthorized  accesses  
Running  a  Program*  
*  Adapted  from  Prof.  
Shen@Rochester
 
UC.  Colorado  Springs  
CS4500/5500  
Source  
program  
Object  
program  
Loadable  
program  
compiler  
linker  
In-­‐memory  
execu0on  
Sta0c  
library  
dynamic  
library  


Compile  and  link  
0me  
o

A  linker  performs  
reloca0on  if  the  memory  
address  is  known    


Load  0me  
o

Must  generate  
relocatable
 code  if  
memory  loca0on  is  not  
known  at  compile  0me  
Reloca-on  and  Protec-on  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  


Reloca0on:  what  address  the  program  will  begin  in  in  memory  
o

Sta0c  reloca0on:  OS  performs  one-­‐0me  change  of  addresses  in  program  
o

Dynamic  reloca0on:  OS  is  able  to  relocate  a  program  at  run0me  


Protec0on:  must  keep  a  program  out  of  other  processes

 par00ons  
Illustration of the relocation problem.

Sta0c  reloca0on  –  OS  can  not  move  it  once  
a  program  is  assigned  a  place  in  memory  
A  Memory  Abstrac-on:  Address  Spaces  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  


Exposing  the  en0re  physical  memory  to  processes  
o

Dangerous,  may  trash  the  OS  
o

Inflexible,  hard  to  run  mul0ple  programs  simultaneously    


Program  should  have  their  own  views  of  memory  
o

The  address  space  –  logical  address  
o

Non-­‐overlapping  address  spaces  –  protec0on  
o

Move  a  program  by  mapping  its  addresses  to  a  different  place  -­‐  
reloca0on  
Dynamic  Reloca-on  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  


OS  dynamically  relocates  programs  in  memory  
o

Two  hardware  registers:  base  and  limit  
o

Hardware  adds  reloca0on  register  (base)  to  virtual  address  
to  get  a  physical  address  
o

Hardware  compares  address  with  limit  register  address  
must  be  less  than  base  
Disadvantage:  two  opera0ons  on  every  memory  access  and  the  addi0on  is  slow  
Dealing  with  Memory  Overload  -­‐  Swapping  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  
Memory  alloca0on  changes  as    
o

processes  come  into  memory  
o

leave  memory  
Shaded  regions  are  unused  memory  (memory  holes)  
°

Swapping:  bring  in  each  process  in  its  
en#rety
,  M-­‐D-­‐M-­‐  …  
°

Key  issues:  alloca0ng  and  de-­‐alloca0ng  memory,  keep  track  of  it  
Why  not  memory  compac-on?  
Another  way  is  to  use  virtual  memory  
Swapping  –  Memory  Growing  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  
(a)  Alloca0ng  space  for  growing  
single  (
data)  segment  
(b)  Alloca0ng  space  for  growing  stack  &  data  segment  
Why  stack  grows  downward?  
Memory  Management  with  Bit  Maps  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  


Part  of  memory  with  5  processes,  3  holes  
o

0ck  marks  show  alloca0on  units  (
what  is  its  desirable  size?
)  
o

shaded  regions  are  free  


Corresponding  
bit  map  (
searching  a  bitmap  for  a  run  of  n  0s?
)
 


Same  informa0on  as  a  
list
 (beCer  using  a  doubly-­‐linked  list)  
°

Keep  track  of  dynamic  memory  usage:  bit  map  and  free  lists  
Memory  Management  with  Linked  Lists  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  
Four
 neighbor  combina0ons  for  the  termina0ng  process  X  
°

De-­‐alloca#ng
 memory  is  to  update  the  list  
Memory  Management  with  Linked  Lists  (2)  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  
°

How  to  
allocate
 memory  for  a  newly  created  process  (or  swapping)  ?  


First  fit:  allocate  the  first  hole  that  is  big  enough  


Best  fit:  allocate  the  smallest  hole  that  is  big
 


Worst  fit:  allocate  the  largest  hole  


How  about  separate  P  and  H  lists  for  searching  speedup?  By  with  what  cost?  
°

Example:  a  block  of  size  2  is  needed  for  memory  alloca0on  
Which  strategy  is  the  best?  
Quick  fit:  search  fast,  merge  slow  
Virtual  Memory  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  
°

Virtual  memory:  the  combined  size  of  the  program,  data,  and  stack  may  
exceed  the  amount  of  physical  memory  available.  


Swapping  with  overlays;  but  hard  and  0me-­‐consuming  to  split  a  program  into  
overlays  by  the  programmer  


What  to  do  more  efficiently?  
Mapping  of  Virtual  addresses  to  Physical  addresses  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  
Logical  program  works  in  its    
con-guous  virtual  address    
space  
Actual  loca-ons  of  the    
data  in  physical  memory  
Address  transla-on  
done  by  MMU  
Paging  and  Its  Terminology  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  
Page  table  gives  the  rela0on    
between  virtual  addresses    
and  physical  memory    
addresses  
 
°

Terms  


Pages  


Page  frames  


Page  hit  


Page  fault  


Page  replacement  
°

Examples:  


MOV  REG,  0  


MOV  REG,  8192  


MOV  REG,  20500  


MOV  REG,  32780  
20K  –  24K:  
     20480  –  24575  
 
24K  –  28K  :    
       24576  –  28671  
 
 
Page  Tables  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  
Two  issues:  
 
 1.  Mapping  must  be  fast  
 
2.  Page  table  can  be  large  
 
Who  handles  page  faults?  
Internal  opera0on  of  MMU  with  16  4  KB  pages  
Structure  of  a  Page  Table  Entry  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  
Virtual  Address  
Virtual  page  number
 
Page  offset  
Who  sets  all  those  bits?  
/  dirty  
Transla-on  Look-­‐aside  Buffers  (TLB)  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  
Taking  advantage  of  Temporal  Locality:  
 
A  way  to  speed  up  address  transla0on  is  to  use  a  special  
cache
 of    
recently  used  page  table  entries    -­‐-­‐    this  has  many  names,  but  the  most  
frequently  used  is  
Transla#on  
Lookaside
 Buffer
 or  
TLB  
Virtual  page  number
Cache Ref/use Dirty
Protection
Physical  Address
 

(virtual page #)




( p h y s i c a l p a g e #)
T L B  a c c e s s  0 m e  c o m p a r a b l e  t o  c a c h e  a c c e s s  0 m e;    
             m u c h  l e s s  t h a n  P a g e  T a b l e  ( u s u a l l y  i n  m a i n  m e m o r y )  a c c e s s  0 m e  
T r a d i 0 o n a l l y,  T L B  m a n a g e m e n t  a n d  h a n d l i n g  w e r e  d o n e  b y  M M U  
H a r d w a r e,  t o d a y,  s o m e  i n  s o w w a r e  /  O S  ( m a n y  R I S C  m a c h i n e s )  
W h o  h a n d l e s  T L B  m a n a g e m e n t  a n d  h a n d l i n g,  s u c h  a s  a  T L B  m i s s?  
A  TLB  Example  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  
A  TLB  to  speed  up  paging  (usually  inside  of  MMU  tradi0onally)  
Page  Table  Size  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  
Given  a  32-­‐bit  virtual  address,    
                     4  KB  pages,    
                     4  bytes  per  page  table  entry  (memory  
addr
.  or  disk  
addr
.)  
 
What  is  the  size  of  the  page  table?
 
The  number  of  page  table  entries:  
 
 
 
2^32  /  2^12  =  2^20  
 
The  total  size  of  page  table:  
 
 
2^20  *  2^2  =  2^22  (4  MB)  
 
When  we  calculate  Page  Table  size,  the  index  itself  (virtual  page  
number)  is  owen  NOT  included!
 
What  if  the  virtual  memory  address  is  64-­‐bit?  
2^64/2^12*2^2  =  2^24  GB  
What  if  2KB  pages?  
2^32/2^11*2^2  =  2^23  (8  MB)  
Mul--­‐level  Page  Tables  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  
Second-level !
page tables
!
(a)32  bit  address  with  2  page  table  fields.                    (b)Two-­‐level  page  tables  
If  only  4  tables  are  needed,    
the  total  size  will  be  2^10*4  =  4KB  
Example-­‐1:  PT1=1,  PT2=3,  Offset=4  
Virtual  address:  
1*2^22+3*2^12+4=  4206596  
               4M                  4K  
Example-­‐2:  given  logical  address  4,206,596  
What  will  be  the  virtual  address  and  where  
are  its  posi0ons  in  the  page  tables    
4206596/4096=1027,  remainder  4  
1027/1024=1,  remainder  3  
0-­‐4095  
4206592-­‐4210687  
Inverted  Page  Tables  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  
°

Inverted  page  table:  one  entry  per  page  frame  in  physical  memory,  instead  of  
one  entry  per  page  of  virtual  address  space.  
Given  a  64-­‐bit  virtual  address,    
                     4  KB  pages,    
                     256  MB  physical  memory  
 
How  many  entries  in  the  Page  Table?  
Home  many  page  frames  instead?  
How  large  is  the  Page  Table  if  one  entry  8B?  
Comparison  of  a  tradi0onal  page  table  with  an  inverted  page  table  
Inverted  Page  Tables  (2)  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  
°

Inverted  page  table:  how  to  execute  virtual-­‐to-­‐physical  transla0on?  


TLB  helps!  But  what  if  a  TLB  miss?  
Integra-ng  TLB,  Cache,  and  VM  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  
Just  like  any  other  cache,  the  TLB  can  be  organized  as  fully  associa0ve,  
           set  associa0ve,  or  direct  mapped  
 
TLBs  are  usually  small,  typically  not  more  than  128  -­‐  256  entries  even  on  
           high  end  machines.    This  permits  fully  associa0ve  
           lookup  on  these  machines.    Most  mid-­‐range  machines  use  small  
           n-­‐way  set  associa0ve  organiza0ons.  
CPU
TLB
Lookup
Cache
Main
Memory
VA
PA
miss
hit
data
Trans-
lation
hit
miss
Translation
with a TLB
 TLB  misses  or  Page  fault,  go  to  Page  Table  transla-on    
 for  disk  page  addresses  
Put  it  all  together:  Linux  and  X86  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  
Logical  address  
cr3  
Page  Global  
Directory  
Page  Upper  
Directory  
Page  Middle  
Directory  
Page  Table  
Page  
Switch  the  cr3  value  
when  context  switching  threads  
and  flush  the  TLB  
A  common  model  for  32-­‐bit  (two-­‐level,  4B  
pte
)  and  64-­‐bit  (four-­‐level,  8B  
pte
)  
SRC/include/
linux
/
sched.h
->
task_struct
->mm->
pgd

SRC/kernel/
sched.c
->
context_switch
->
switch_mm

Summary  
Ref.  MOS3E,  OS@Aus0n,  Columbia,  Rochester  
UC.  Colorado  Springs  
CS4500/5500  


Two  tasks  of  memory  management  


Why  memory  abstrac0on?  


Manage  free  memory  


Two  ways  to  deal  with  memory  overload  
o

Swapping  and  virtual  memory  


Virtual  memory  


Paging  and  Page  table