Operating Systems

Outline

• Today's Pictures
• Memory hierarchy, segments and memory maps
• Review: Powers of Two, Bit Fields and Trees
• Virtual memory (introduction)
• Memory management
• Performance measurement statistics

The first lecture is about addresses and memory management: the different segments, stacks and dynamic memory, etc.

The second lecture will pick up with the buddy system, review the basic concepts of bit fields, then study the mechanisms we use to achieve address translation, especially the data structure known as the page table. The third lecture will then study how we make decisions about virtual memory.

Goal of Memory Management

The primary goal of memory management is to support dynamic growth and shrinking of resources. Why?

• programs may not be able to allocate all needed memory at compile and program load time
• safe sharing of memory
  (capacity management for correctness and fairness, and security)

Multi-level Memory Hierarchy

Most computer systems support a multi-level memory hierarchy:

• Registers
• Cache (sometimes multi-level itself)
• Main memory
• Disk
• (Tape, in some supercomputing systems)

where all of the levels are managed by the compiler and operating system together to be transparent to the application programmer, except for performance. Sometimes the transparency is partially aided by hardware, as in the case of cache memory.

Four questions on the memory hierarchy:

• Where can the item be placed in memory? (placement)
• How is the memory found? (naming)
• When there's not enough memory, what gets removed or replaced? (replacement)
• What happens on write? (write strategy)

We will go into these four questions in more detail at the end of this lecture, and next time.

Memory Map

The most important concept tool for visualizing the location of data is the memory map. Memory maps can be drawn with high addresses at the top or the bottom.

See pointer-print.c.

(Image is a Linux process memory map, from NCSU.)

Memory in a Unix process can be divided into several segments:

• text: the program itself (i.e., the text the CPU uses to execute the program, not human-readable text!)
• data: holds the user's data; can be divided into initialized data (e.g., variables whose values are known at compile time) and unitialized data (called the BSS segment, for historical reasons).
• shared libraries: these are technically in a separate segment, to simplify loading and sharing of the libraries.
• user stack: the program's stack. Question: how is this handled with multiple threads? How big is it?
• kernel: the user program cannot directly access code or variables in the kernel's own space, but part of that is technically included in the process's address space, even without permission to touch the pages. This makes system calls faster.

Goal of Memory Management (reiterate)

• programs may not be able to allocate all needed memory at compile and program load time
• safe sharing of memory
  (capacity management for correctness and fairness, and security)

Basic Techniques

Sometimes, memory is wasted due to a process known as fragmentation. Fragmentation occurs when various objects are created and deleted, leaving behind holes in the memory space. The memory manager's job is to see that applications can always get the memory they need, by using an algorithm that minimizes fragmentation and keeps holes under control.

Several different algorithms can be used to assign memory to the next request that comes in:

• first fit
• best fit
• worst fit
• buddy system

[rdv@dhcp-143-236 ~]$ more /proc/buddyinfo 
Node 0, zone      DMA      2      4      3      4      5      4      2      2      3      1      1 
Node 0, zone   Normal    242    110    156    111     78     43     20      7      7      4      3 
Node 0, zone  HighMem      2      0      0      1      1      1      0      0      0      0      0 

See this page or one in Japanese for a description of the buddyinfo output.

Simple Multiprogramming Memory Management

• Base and limit registers, as in the Cray-1.
• Complete swapping of processes.

The original form of multiprogramming actually involved swapping complete processes into and out of memory, to a special reserved area of disk (or drum). This approach allowed each process to act as if it owned all of the memory in the system, without worrying about other processes. However, swapping a process out and in is not fast!

A few weeks ago, you had bit field extraction as a homework set. This lecture is why you had that. Let's do some examples...

See the program bitwise-funzies-rdv2.c.

We have also seen tree structures. Let's take a quick look at a fixed type of non-binary tree.

• VM hides some of the layers of the memory hierarchy.
• VM's most common use is to make memory appear larger than it is.
• VM also provides protection and naming, and those are independent of the above role.

In most modern microprocessors intended for general-purpose use, a memory management unit, or MMU, is built into the hardware. The MMU's job is to translate virtual addresses into physical addresses.

Page Tables

(thanks to Chishiro for spotting those excellent diagrams on Wikipedia.)

Viritual memory is usually done by dividing memory up into pages, which in Unix systems are typically, but not necessarily, four kilobytes (4KB) each. Linux, however, is set up to support page sizes of any power of two from 4KB to 4GB, though not every architecture supports them all.

The page table is the data structure that holds the mapping from virtual to physical addresses. The page frame is the actual physical storage in memory.

The simplest approach would be a large, flat page table with one entry per page. The entries are known as page table entries, or PTEs. However, this approach results in a page table that is too large to fit inside the MMU itself, meaning that it has to be in memory. In fact, for a 4GB address space, with 32-bit PTEs and 4KB pages, the page table alone is 4MB! That's big when you consider that there might be a hundred processes running on your system.

The translation from virtual to physical address must be fast. This fact argues for as much of the translation as possible to be done in hardware, but the tradeoff is more complex hardware, and more expensive process switches. Since it is not practical to put the entire page table in the MMU, the MMU includes what is called the TLB: translation lookaside buffer.

Linux Page Tables

First, we're going to look at some examples from the Linux kernel source. (Similarly, the FreeBSD kernel is browsable online.)

(Images from O'Reilly's book on Linux device drivers, and from lvsp.org.)

We don't have time to go into the details right now, but you should be aware that doing the page tables for a 64-bit processor is a lot more complicated, when performance is taken into consideration.

Linux originally used a three-level page table system, later extended to four. Each level supports 512 entries: "With Andi's patch, the x86-64 architecture implements a 512-entry PML4 directory, 512-entry PGD, 512-entry PMD, and 512-entry PTE. After various deductions, that is sufficient to implement a 128TB address space, which should last for a little while," says Linux Weekly News.

#define IA64_MAX_PHYS_BITS      50      /* max. number of physical address bits (architected) */
...
/*
 * Definitions for fourth level:
 */
#define PTRS_PER_PTE    (__IA64_UL(1) << (PTRS_PER_PTD_SHIFT))

Normal Gaussian Distribution

gnuplot> delta=0.01
gnuplot> g(x) = (norm(x+delta)-norm(x))/delta
gnuplot> set title "Gaussian Normal Density"
gnuplot> plot [-4:4] [0:0.5] g(x) notitle lw 3
gnuplot> set term post eps "Helvetica" 24
gnuplot> set out "normal.eps"
gnuplot> replot
[rdv@localhost systems-software]$ file normal.eps
normal.eps: PostScript document text conforming at level 2.0 - type EPS
[rdv@localhost systems-software]$ convert -size 720x504 -resize 720x504 normal.eps normal.png
[rdv@localhost systems-software]$ file !$
file normal.png
normal.png: PNG image data, 720 x 504, 16-bit/color RGB, non-interlaced
[rdv@localhost systems-software]$ display !$
display normal.png

The normal distribution is a continuous function; its discrete counterpart is the Poisson distribution.

Other Distributions

Clock Granularity Artifacts

startclock();
for ( i = 0 ; i < NUMREPS ; i++ )
  do_short_operation();
stopclock();

A few of you have already hit on using the Intel processor Time Stamp Counter (TSC). That's an excellent idea, but it does have drawbacks:

• It's not portable
• If clock frequency changes, it's not wall clock time
• It can't account for multitasking

Error Bars

Linear Fit

Recently, for a project, I adapted the function gsl_fit_linear for some code. The adaptation was actually a hassle, so I don't recommend you do it, but for what it's worth, here's the code itself from the GNU Scientific Library (GSL).

/* Fit the data (x_i, y_i) to the linear relationship 

   Y = c0 + c1 x

   returning, 

   c0, c1  --  coefficients
   cov00, cov01, cov11  --  variance-covariance matrix of c0 and c1,
   sumsq   --   sum of squares of residuals 

   This fit can be used in the case where the errors for the data are
   uknown, but assumed equal for all points. The resulting
   variance-covariance matrix estimates the error in the coefficients
   from the observed variance of the points around the best fit line.
*/

int
gsl_fit_linear (const double *x, const size_t xstride,
                const double *y, const size_t ystride,
                const size_t n,
                double *c0, double *c1,
                double *cov_00, double *cov_01, double *cov_11, double *sumsq)
{
  double m_x = 0, m_y = 0, m_dx2 = 0, m_dxdy = 0;

  size_t i;

  for (i = 0; i < n; i++)
    {
      m_x += (x[i * xstride] - m_x) / (i + 1.0);
      m_y += (y[i * ystride] - m_y) / (i + 1.0);
    }

  for (i = 0; i < n; i++)
    {
      const double dx = x[i * xstride] - m_x;
      const double dy = y[i * ystride] - m_y;

      m_dx2 += (dx * dx - m_dx2) / (i + 1.0);
      m_dxdy += (dx * dy - m_dxdy) / (i + 1.0);
    }

  /* In terms of y = a + b x */

  {
    double s2 = 0, d2 = 0;
    double b = m_dxdy / m_dx2;
    double a = m_y - m_x * b;

    *c0 = a;
    *c1 = b;

    /* Compute chi^2 = \sum (y_i - (a + b * x_i))^2 */

    for (i = 0; i < n; i++)
      {
        const double dx = x[i * xstride] - m_x;
        const double dy = y[i * ystride] - m_y;
        const double d = dy - b * dx;
        d2 += d * d;
      }

    s2 = d2 / (n - 2.0);        /* chisq per degree of freedom */

    *cov_00 = s2 * (1.0 / n) * (1 + m_x * m_x / m_dx2);
    *cov_11 = s2 * 1.0 / (n * m_dx2);

    *cov_01 = s2 * (-m_x) / (n * m_dx2);

    *sumsq = d2;
  }

  return GSL_SUCCESS;
}

Homework

1. Implement a simple simulation of a buddy system memory allocator, as in Exercise 5.3 of the "Fundamentals of System Software" lecture notes, uploaded into SFS or available here.

Next Lecture

Next lecture (after this set of three):

第8回 5月7日 ページ置換アルゴリズム
Lecture 8, May 7: Hypervisors and System Virtualization

Readings for Next Time and Followup for This Time

An old set of readings I used to recommend:

• Tanenbaum, 4.5-4.7.
• "The Cathedral and the Bazaar"

Followup from this time:

• Stanford CS Education Library has a good collection of materials on pointers. Their video titled "Pointer Fun With Binky" is also available on Wikimedia.

その他 Additional Information

• Rodney Van Meterのホームページ (home page)
• 村井研究室 Murai Lab