Memory Management

1
Memory Management

• Key issues
• Allocating the main memory (RAM) for use by
  different processes
• Mapping addresses used in a process to addresses
  in physical memory
• Protecting memory owned by one process from being
  accessed by another
• Making good use of the different memory systems
  of the computer
• Many programs are usually in memory at the same
  time, but where? The actual physical memory
  addresses an executable image uses are likely to
  be different each time it is loaded, and are
  certainly not known when it is created by the
  compiler and linker.
• If a process goes haywire, must ensure it cannot
  corrupt memory belonging to another process, and
  in particular cannot corrupt the operating system
  processes. Even if it doesnt go haywire, same
  applies.
• Ideally, each process should be able to use the
  full address space of the machine. In practice
  only a small fraction of this amount of RAM will
  be available to a process, but maybe we can use
  the disc to pretend.
• Many different types of memory, from registers to
  caches to RAM to discs. Access times vary by
  about ten million. Registers typically hold less
  than 1 kilobyte, discs may hold ten gigabytes,
  factor of ten million again. How best to exploit
  these different systems.

2
Virtual addressing 1

• N.B. not the same as Virtual memory see later
• The logical memory addresses used by a process
  are mapped to the actual physical addresses
  in RAM, which can be quite different.
• Usually done by mapping e.g. 4 kilobyte pages
  of logical addresses into 4 kilobyte page
  frames of physical RAM.
• e.g. assuming a 32 bit address space, use the low
  order 12 bits to address bytes both within the
  page and within the page frame, but replace the
  high order 20 bits that denote the logical page
  with a quite different 20 bits to address a
  physical page frame.
• The mapping from logical page number to physical
  page frame could be done using a page table,
  where the index into the table is the logical
  page number, and each entry is a physical page
  number. Each process would have its own page
  table set up by the operating system, containg
  references to the physical memory allocated to
  the process by the OS.
• In practice, two tables are often used. The page
  directory table is indexed into by the top 10
  bits of the virtual address, and gives the
  physical page frame where the page table
  starts. The page table is then indexed into by
  the next 10 bits of the virtual address, and
  gives the physical page frame address.
• The start address of the page directory table for
  a process is usually placed in a special
  register, and stored in the PCB for the process.

3
Virtual Addressing 2

• The page table based approach has many advantages
• Memory used by a process can appear contiguous to
  it, even though the physical page page frames are
  all over the place. Fragmentation in the use of
  RAM becomes largely irrelevant.
• The same page frame in RAM can be mapped into the
  address space of many different processes this
  is particularly useful for read-only pages.
• The page table entry can be extended to contain
  other information, for example the access rights
  of the process for that page, whether it has been
  changed, whether it can be accessed in user
  mode, how long since it was last used, how often
  it has been used.
• A process can only see the physical page frames
  referenced in its page tables the others are
  protected from it for good security need to
  ensure that a process cannot change its own page
  tables, and need to handle references to virtual
  addresses for which there is no entry
• The scheme can be extended naturally to support
  virtual memory, where the physical page is not
  in RAM at all, but is out on a disc see later.
• However, it effectively requires additional
  hardware support the TLB

4
Virtual Addressing 3

• The model presented so far suggests that each
  memory access involves accessing the page
  directory table to get the start of the page
  table accessing the page table to get the
  actual page frame accessing the page
  frame to get the data
• Rather a lot of work for one memory access!
• In practice, access to computer memory usually
  displays locality of reference the next byte
  accessed is likely to be in the same page frame
  as a recently accessed byte. So if the physical
  page frame corresponding to a virtual page is
  remembered, all the looking up of tables can be
  short circuited when another reference to a byte
  in that page occurs.
• Most systems provide a translation lookaside
  buffer (TLB) containing (virtual page address,
  physical page frame address) pairs, and
  implemented as an associative memory all the
  virtual page addresses can be compared with a
  given virtual page in one go, and the
  corresponding physical page frame address
  returned. This can usually be done in parallel
  with some other part of the operation of the CPU,
  so that the mapping from virtual to physical adds
  no extra delay at all.
• Of course, if the no entry exists in the TLB for
  a particular virtual page, the looking up
  rigmarole above has to happen the TLB is then
  updated, maybe overwriting the least recently
  used entry.

5
Virtual Memory 1

• Its easy to see how to extend the page table
  idea so that the physical data is on disc rather
  than in RAM.
• Since disc is maybe ten million times slower than
  RAM, this seems little use at first sight.
• However, most programs display locality of
  reference in space and in time memory accesses
  tend to be to locations near those used recently
  a large program may spend nearly all its time
  in just a few small parts of the code. If this is
  the case, only these active parts of the program
  need to be in precious RAM. The rest can be left
  on disc, and pages be brought into memory from
  disc when required. As this should seldom happen,
  the overhead is tolerable - of course, if the
  program does not display locality of reference
  performance will be disastrous.
• The memory needed by a process for its current
  operations, its working set, needs to be
  allocated to it as RAM, otherwise the system will
  spend most of its time on disc accesses, and
  little processing will be done thrashing
• However, if an adequate RAM allocation is made,
  even though much less than that required to hold
  the whole program, it can seem as if the whole
  program is in RAM - virtual memory
• This is particularly useful when many processes
  are in memory at once they can all be kept
  happy without any of them being fully in RAM

6
Virtual Memory 2

• Accessing memory now goes something like this
• Try the TLB with the virtual page
• if not a TLB hit, OS uses the page tables
• if the page not in RAM, page fault
• OS decides which page in RAM to replace
• if page was changed writes it to disk first
• update page table to indicate this page now on
  disc
• gets required page from disc into RAM
• update page table entry for virtual address
• update TLB
• use TLB entry to give physical page frame
• This works very well, as long as each process has
  enough RAM to hold its working set
• One significant issue is the replacement policy
  used by the OS next year

7
Virtual Memory 3

• Making all this work efficiently is a source of
  considerable complexity in operating systems.
• The OS typically maintains a table of free pages
  and a table of modified pages, with the later
  only written back to disc and freed when free
  pages run low. Modified pages may be zeroised
  before being freed for security reasons.
• To store pages that have been modified, the OS
  will typically use a pagefile. Pages that were
  not modified can simply be reloaded again from
  disc.
• The OS must also set up and maintain the page
  directories and page tables for each of the
  processes
• In addition, the OS may need to totally swap out
  some process from memory to make RAM space
  available, making the corresponding changes to
  all the tables.
• And all of this can be upset if programs are
  written really badly, so that they do not display
  locality of reference