システム・ソフトウェア
System Software / Operating Systemsオペレーティングシステム

Outline

• We're on Mars!
• Structure of a research proposal
• Performance measurement statistic統計s
• Memory management管理
• Virtual memory仮そう記録 (introduction)

The Phoenix Spacecraft has landed near Mars' north pole. And, like earlier JPL-supported robotic missions, it runs the VxWorks operating systemオペレーティングシステム.

• What is your hypothesis, question or goal?
  • "I hypothesize that SELinux is measurably slower than vanilla Linux."
  • "Why does Microsoft Word load faster on Vista than XP?"
  • "I will build an OS call to measure the distance from the CPU to the moon." (With a goal of building something, you must describe why it is valuable, as well.)
• What will be the output of a successful project? (How will you know when you're done?)
• What are the midterm milestones? (How will you know if you are on schedule to finish or not?)
• What equipment and skills do you need in order to succeed? Do you have them, or a good plan to acquire them?

• What will you learn if the project is successful?
• What will you learn if the project fails?

• Are you measuring throughput, latency, or both?
• In particular for measuring latency, do you know roughly what the size of the phenomenon is that you're looking for? If it's a difference of a few instructions, that's hard to measure; how will you do it?
• What variables will be varied, and what variables will be fixed?
• What stastical techniques will be necessary to confirm your hypothesis?

• Why is your project important?
  • Who will it affect?
  • How big is the effect? (more of a result than part of the proposal, but you should have some expectation that what you are doing is likely to have an effect big enough to care about.)
  • As technology changes (in particular, at the moment, as multicore chips become standard), are your results likely to still be applicable?
• Who else has worked on the same or similar projects?
  • Why is your approach "better"? ("Different" is not usually reason enough by itself.)
  • Are there problems with their approach? Is their data now old?

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 processプロセスor 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;
}

Goal of Memory Management管理

• 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

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

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)

Pointers and Memory Addresses

If you program in C at all, you should be familiar with pointers by now, but let me go over it quickly...

Memory Map

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 

Simple Multiprogramming Memory Management管理

• Base and limit registers, as in the Cray-1.
• Complete swapping of processプロセスes.

The original form of multiprogramming actually involved swapping complete processプロセスes 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 processプロセスes. However, swapping a processプロセス out and in is not fast!

• 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.

Page Tables

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 processプロセスes running on your system.

The solution is multi-level page tables. As the size of the processプロセス grows, additional pages are allocated, and when they are allocated the matching part of the page table is filled in.

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

(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 processプロセスor is a lot more complicated, when performance is taken into consideration.

Linux uses a three-level page table system. 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))

Paging

Homeworkかだい

1. Experimentally construct a rough memory map for an application on your operating systemオペレーティングシステム.
   1. Write a program that prints out (in hexadecimal十六進法) the addresses of the following:
      1. main()
      2. a variable on the outermost stack frame (main()'s stack frame)
      3. a variable on the stack frame of a recursively-called function機能・関数, called to a depth of five times
      4. a statically-defined but uninitialized variable
      5. a statically-defined, initialized variable
      6. several large chunks of malloc()ed memory
      7. a library routine, such as strcpy()
      8. a system callシステムコール wrapper, such as the one for write()
   2. Take that information情報 and draw a memory map for your OS. It should indicate which direction the stack and the heap grow in. An ASCII picture is okay, or you can use a drawing program of some sort if you wish.
      1. How big is the distance between your stack and your heap?
      2. Was your program compiled with static libraries or shared libraries?
2. Extend your project proposal to answer the questions above.

Next Lecture

第7回 5月22日 ページ置換アルゴリズム
Lecture 7, June 3: Page Replacementページ置き換え Algorithms
We will also talk a little bit about memory-mapped files.

Readings for next week:

• Tanenbaum, 4.5-4.7.

Followup from this week:

• Announcement of VxWorks running on Phoenix
• 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