システム・ソフトウェア
System Software / Operating Systems

Let's go back to last week and look at some of the history we didn't have time to finish.

Recall that mainframes went from bare metal, to batch systems, to unprotected multiprogramming, to protected multi-user systems. PC operating systems followed the same pattern, and embedded OSes for devices such as PDAs are following the same pattern.

最初にメインフレームとして利用されていたプログラマブルコンピューターは、 金属自身で(つまり部品を切り替えて)プログラムをつくっていました． 次にバッチシステムが開発されました。 そのあと、保護されないマルチプログラミング用のOSが出現し， 次に保護のあるOSをできました。 PC用と組み込み用のOSは同じ道をたどってきました．

Finally, remember that we discussed the light cone of information and its impact on systems, where we must consider that information is always distributed (and therefore out of date), and that systems are definitely concurrent.

I asked you to read the Levin and Redell paper. That paper will help you learn how to understand a computer system, as well as the larger issue of learning how to both analyze existing research, as well as how to present your own research. Thinking about this issue will help with writing your master's thesis.

前回， Levin and Redell paperを読むという宿題を出しました． この文章はコンピュータシステムへの理解だけではなく， どのように既存研究を分析するか， どのように自分の研究を提供するかといった知識を与えてくれるでしょう． これらの問題に取り組むことはあなたの修士論文の助けになるでしょう．

Everyone always wants to describe what they did, rather than why they did it. A good paper must describe why, and, ultimately, whether or not what you did worked, and how you know.

誰もが何をしたのかを話したがり， 何故それが必要かを説明しません． そして，どういう結果が出て，どうしてそれを知ったのかを説明しないのです．

When you present a project, or an idea, to me, I expect the following:

皆さんはプロジェクトあるいはアイデアを私に提案するとき， 以下のことを考えます．

You will find a slightly updated version of the questions from Levin and Redell here.

また，皆さんはLevin と Redellからの若干のアップデートされた質問を ここ.

非常に簡単にではありますが，いくつかのOSの種類を説明します． 本抗議では，多目的PCのOS(訳注:皆さんが普段使うようなOSです) について解決しますが，世の中には多くのOSが存在します． それらの多くの特徴はほとんど変わらず， 新しいOSは従来のOSから大きく変わるものではないです．

• Mainframe(メインフレーム)
• Server(サーバ)
• (Tanenbaum lists multiprocessor, but all OSes today must be MP-capable/タネンバウムはマルチプロセッサをあげていますが，最近のOSはマルチプロセッサをサポートしています)
• PC
• Real-Time(リアルタイムOS)
• Embedded （組込み用）
• Smart card/micro-OS(スマートカード/マイクロOS)

The two photos above demonstrate two critical concepts in operating systems:

• Hard real-time operation
• Competition for resources

We will see these two concepts again in later lectures.

システムコールはOSとユーザランドプログラムのインタフェースを 定義します． 基本的なシステムコールは以下のように分類されます．

• process management
• file management and I/O
• directory and file system management
• network and device I/O (including graphic display)

• プロセス管理
• ファイル管理, ファイルI/O
• ディレクトリ/ファイルシステムの管理
• ネットワークI/OとデバイスI/O(グラフィックもこの一部です)

Unix，あるいはその影響を強く受けているOS上で， 最後のカテゴリは通常，ファイルI/Oです． しかし，通常いくつかのシステムコールがファイルI/Oには必要となります． たとえば，ネットワーク接続が正常に開いているのか，などです．

前回の授業では， リソース管理， データ転送と 名前空間 という重要なOSの要素について扱ってきました． これらのシステムコースは，アプリケーションの要求する OSの機能を提供する要素です．

システムコールは通常のライブラリとは違う機能を持ちます． 一般的な多くのOS環境はアプリケーションプログラマが使用したがる 標準化されているライブラリの機能を提供します． (ライブラリがOSの機能かどうかについては議論の余地があるけれども) では，システムコールとライブラリは何が違うのでしょうか？ ライブラリはシステムコールを呼ぶものであってもユーザランドからスタートします． ライブラリファンクションは， 文字列の成型や，数式の計算などを処理します． システムコールは一般的に，ディスクドライバ，その上のファイル，保護された領域など にアクセスするために呼ばれます．

前回，我々はネーミングというOSの重要な機能について議論しました． 通常，人間は可読なシステムコールの名前(たとえば，writeのような)を用います． しかし，OS自身は人間が可読な名前を持ちません． つまり，Cコンパイラのヘッダファイルが，マシンが用いる名前と人間の用いる名前を 変換しているのです．

さて，ここにLinux2.6.19のコードの一部を示します．

[rdv@2 ~]$ more /usr/include/asm/unistd.h 
#ifndef _ASM_I386_UNISTD_H_
#define _ASM_I386_UNISTD_H_

/*
 * This file contains the system call numbers.
 */

#define __NR_restart_syscall      0
#define __NR_exit                 1
#define __NR_fork                 2
#define __NR_read                 3
#define __NR_write                4
#define __NR_open                 5
#define __NR_close                6
...
#define __NR_move_pages         317
#define __NR_getcpu             318
#define __NR_epoll_pwait        319

#endif /* _ASM_I386_UNISTD_H_ */

Linuxには319のシステムコールが存在することがわかります．

(On a Mac, the corresponding file is /usr/include/sys/syscall.h. How many system calls are there? Notice the correspondence between Linux and MacOS.)

システムコール処理はいくつかのフェーズに分かれます．

• user process: prepare the arguments
• user process: execute trap or interrupt to reach into kernel
• kernel: determine which system call is being requested
• kernel: verify permissions, size, type, etc. of arguments (this is a great opportunity for a security hole!)
• kernel: execute system call; if I/O wait or other wait is required, put the process to sleep
• kernel: when I/O completes, clean up request structures (timers, any allocated memory, etc.), set errno and the return value for the system call
• kernel: return
• user process: finish application-side processing of the call.

• ユーザランド: 引数の準備
• ユーザランド: カーネルランドで処理するためのトラップあるいは割り込み(コンテキストスイッチ)
• カーネルランド: どのシステムコールが呼ばれているかを確定する
• カーネルランド: 引数として与えられた権限，サイズ，種類などを確認する(これはセキュリティホールの原因となる１つの大きな要因となってきた！)
• カーネルランド: システムコールを実行．I/O待ちなどが生じたらプロセスをsleep状態にする
• カーネルランド: I/O処理が終了するとタイマーや割り当てたメモリ領域を解放し，errnoを設定する．そして，システムコールの戻り値を返す．
• カーネルランド: ユーザランドに戻る（コンテキストスイッチ）
• ユーザランド: アプリケーションサイドのシステムコール処理を終える

アプリケーション側では，ライブラリの中でシステムコールに飛ぶかもしれませんし，飛ばないかもしれません． コンパイルではこのことを非常に注意深く扱います．

このような本質的な構造が， リモートサーバとの接続もローカルサーバのように扱われているのです． 繰り返しますが，我々の原則である分散かつ並列に処理可能である， ということが実現されているのです．

ほとんどのシステムコールは同期型です． 同期型とは，アプリケーションがシステムコールの動作を完了するまで 停止するということです． (もちろん場合によってはエラーを返すこともあります)

setuidの詳細をみてみましょう．

_syscall1(int,setuid,uid_t,uid);
which will expand to:

_setuid:
  subl $4,%exp
  pushl %ebx
  movzwl 12(%esp),%eax
  movl %eax,4(%esp)
  movl $23,%eax
  movl 4(%esp),%ebx
  int $0x80
  movl %eax,%edx
  testl %edx,%edx
  jge L2
  negl %edx
  movl %edx,_errno
  movl $-1,%eax
  popl %ebx
  addl $4,%esp
  ret
L2:
  movl %edx,%eax
  popl %ebx
  addl $4,%esp
  ret

このコードは少し古いですが重要な部分は残っています．

LinuxディストリビューションのC言語の行数は，

• C files: 5.6 million lines(5,600,000行)
• header (.h) files: 1.36M lines(1,360,000行))

なんということだ！これを印刷したら10万ページにもなるじゃないか！ 最初のUnixカーネルは5000行だったというのに今のLinuxカーネルは17,000ファイルもある！ LinuxはKISS: keep it simple, stupidという基礎的な概念を守っていてもいいのにね．

• arch: 934869
  • 25 types of processors supported
  • example: i386: 178 .c files, 68868 lines
• block (basic disk drive scheduling): 11551
• crypto: 15514
• drivers: 3029159
• fs (file systems): 640300
  • more than fifty different file systems (disk and network supported)
  • example: ext3: 22 .c files, 15597 lines
• init: 2854
• kernel: 66498
• lib: 19195
• mm (memory management): 37655
• net: 438745
• scripts: 15673
• security: 23368
• sound: 394244

全体量の半分以上と３分の一ものだいるが， さまざまなデバイスのために用意されています． そして，そのほとんどが実際にシステムでは使われないのです．

Linux Kernelのハッカーたちは，コメントは記入するので，大きさは倍くらい なっていると考えられます。ただし，以下のものは含まれていないことに注意 してください．

• shell (bash, etc.)
• fundamental utilities: file system mount, network management, etc.
• X Window System
• GNOME

また，元のUNIXでは以下のものも含まれないのです．

• virtual memory/仮想メモリ
• networking (of any form)/ネットワーク
• parallel processing/並列処理

このレベルのシステムでは，十分な定義がされた最低限の過程を隠した 高機能なインタフェースが極めて重要です． しかしながら，最初の実装を捨てるためにLampsonのコマンドを守り， ほぼすべてバーチャルメモリサブシステムを持つLinuxは， よくに(windowsのように)書き換えられている． 本抗議では，これらのシステムをどのようにエンジニアリングしていくか を話す予定です．

Schedule and Grading

• Project and team proposals due: April 23
• Review of proposals returned: May 7
• Revised project proposals due: May 14
• Final approval of projects, implementation begins: May 21
• Mid-term progress review: June 18
• Final evaluation of projects (face-to-face): July 16-26

That gives you seven to eight weeks to actually implement your project. I would expect that your project will take 30-40 hours total, including writing and debugging code, taking data, analyzing the data, and writing up a report of the results. This is actually not very much time for a project, so they must be sized appropriately. (I think I said 40-60 last week, but that's too high.)

Your grade on your project will be 60% of your total grade, split 10% for the mid-term progress review, and 50% for the final evaluation. The things I will look for are those detailed in the Levin and Redell paper. Because many of your projects will involve performance measurements, I also expect data with error bars and carefully designed experiments. One great book on the topic is Jain, The Art of Computer Systems Performance Analysis, but there are probably also good books available in Japanese.

Implementation

Some people have asked what language they must write their program(s) in. I don't care what language you use; I care what you learn about the operating system. In order to learn about the OS, a low-overhead, predictable, compiled language is probably preferable. C would be the obvious choice. Interpreted scripting languages are probably bad choices.

Likewise, there is no requirement to perform your project on a particular operating system. Class lectures will focus on principles highlighted by Unix and Linux examples, as above. The importance of Unix in the history of operating systems cannot be overstated, and Linux and MacOS are (arguably) its most vibrant current implementations; students must have some familiarity with the basic ideas of Unix. However, if your OS of choice is Windows, you will learn a great deal by comparing concepts from lectures and the book with what you see on your Windows machine. One obvious advantage of Linux is the easy availability of source code, turning "black box" experiments into "white box" ones.

The first step in either research or development is to identify a problem. Most of these projects will help you carefully characterize a system problem that you might want to attack more thoroughly in research later. It's okay by me if this is related to your work in your lab for your thesis.

Project Suggestions

The ideal project for this class is probably a performance measurement of the system. Examples include:

• Redo, almost fifteen years later, the measurements in my USENIX paper, Observing the Effects of Multi-Zone Disks (although this is more hardware than software).
• Evaluate the performance of the file system as directories get broader. When there are a thousand files in a directory, how long does it take to look up a file name? When there are a million? (Your file system will likely fail before you get to a million!) Evaluate the performance of the file system as directories get deeper. Does it take constant time to create a new directory? How long does it take to look up a file name as the path gets deeper? Does the file system refuse to go past a certain depth? Is there a limit on total path name length, or is it a limit on the number of directories you've descended? You must characterize both cold-cache and warm-cache performance.
• Shared libraries are valuable due to their memory savings, but they are complicated. Compare in detail the performance of a program using a shared library routine such as puts() with one that uses the same routine, but compiled in directly. Be careful to separate out the costs of the system call itself, the library function, and the overhead of finding and loading the shared library. In addition to measurement, you will probably need to actually count instructions manually, using a debugger. The basic C library will certainly already be in memory; can you find an obscure library that has to be loaded from disk, and determine the overhead of the load?
• Measure the CPU cost of software RAID (obviously, this requires access to a machine that uses software RAID!).
• Compare the cost of malloc() and free() when using multiple threads and using a single thread. Compare when more than one thread is trying to allocate memory, and when multiple threads exist but only one is doing allocation. This project is especially interesting if you do both C and C++; the C++ new() operator will do some surprising things.
• Does the file system on your machine allow multiple processes to open the same file for write? If two processes try to write at the same time, what happens? Is the behavior different if each write is the size of a single page (4KB, usually) or if it's an odd size? Is the behavior different over NFS (from the same or two different machines) as it is locally?
• Measure the performance of TCP networking on your machine. Determine how many times an incoming or outgoing packet must be copied, and how many times it will cross the memory bus (note that these are not necessarily the same number!). Count how many instructions it takes to process an incoming TCP packet. How many instructions are in the interrupt handler for your link layer (presumably Ethernet)?
• Determine how much buffering is needed for smooth audio or video playback. This is tricky, because the OS will be prefetching and caching data, as well.
• Choose an important application and compare its performance on Linux, cygwin, and native Windows.
• IBM has tools to help you make your Linux system boot faster. Similar tools probably exist for Windows or FreeBSD. If not, porting the tools to one of those operating systems would be valuable.
• Everybody complains that starting applications is slow. Take a large app (Evolution, Firefox, etc.) and run strace or the equivalent on it, tracking all of the files that are opened and system calls that are made. Provide details on those: how many bytes are read and written, etc. Can this process be improved using prefetching?
• The paper Scalable synchronous queues, by Scherer et al., presents a new means of managing concurrency (which we will see in lecture 4). Can you simulate something similar in a simple multi-threaded program?
• Many OSes these days can report the battery capacity to several digits of precision. Can you use that ability to determine how much power each component of the sytem requires? Display, wireless network adapter, disk drive?

I will ask you not just what happened, but why it happened. In most cases, you should be able to point to some kernel source code, or a conference paper, design document, book, or web site that supports your understanding of why the system behaves the way it does. For most of these projects, I will also ask you to predict what will happen as technology continues to improve: modest improvements in clock speed and disk speed, significant increases in number of processors and disk capacity.

Previous Years' Projects

• Kanai-san investigated the behavior of several systems when faced with many different IPv6 Router Advertisements. He got probably the most interesting results of any student. He discovered a security hole which resulted in security reports to several OS vendors, doing a real service to the world.
• One student had noticed that a particular application performed well on Windows XP but not on Vista. He investigated that difference, determining how many system calls were made, how long they took, etc.
• One student had noticed that his web server performed poorly when the log file size exceeded a certain size, and investigated why.
• One investigated the performance and accuracy of sleep timers.
• One investigated the impact of varying the security level of the system on various system calls, using lmbench.

Others

• Spring 2000
• Fall 2000
• 1998

Readings

There will be readings from the textbook assigned almost every week. Those are for your own benefit; you are not required to keep notes on them. There will also be five papers (in English) that are assigned reading, for which you are required to post a summary and comments with your homework. They will be assigned through the semester, but FYI, a summary:

• Levin and Redell, An Evaluation of the Ninth SOSP Submissions -or- How (and How Not) to Write a Good Systems Paper
  • You will find a slightly updated version of the questions from Levin and Redell here.
• Lampson, Hints for Computer System Design
• Scherer et al., Scalable synchronous queues.
• Raymond,"The Cathedral and the Bazaar"
• (Fifth paper TBD.)

1. This week we have talked about system calls. Take your "Hello, world" program from last week and produce the assembler output from the compiler. Include the assembler file in your homework.
   1. Identify the instruction that calls the string output function. Is it a library function or a system call? How can you tell?
   2. Identify the arguments to the function. How many are there?
   3. If your string output function is a library function rather than system call, can you find the function and instruction that actually does the trap into the kernel?
2. Unfortunately, even "Hello, world" is a little bit complicated. Take the following even shorter program and repeat the above exercise.
   

   #include <unistd.h>
   
   int main() {
     char *buf = "123";
           write(1, buf, 3);
           return 0;
   }
   

   (Hint: if you are using Linux, some of the information you need to complete this exercise is above in the lecture notes.)
3. Find a list of all of the system calls on the OS of your choice, and post it (or a link) in your homework. How many are there?
4. 2-3 page report on the "Hints for Computer System Design" paper.
5. How long did it take you to complete this homework?

Next Lecture

第3回 4月23日 プロセスとスレッド
Lecture 3, April 23: Processes and Threads

Readings for Next Week and Followup for This Week

Follow-up readings for this week:

• Tanenbaum, Sec. 1.3, 1.6
• Lampson, Hints for Computer System Design

• Tanenbaum, 2.1-2.2

• Class Syllabus and Top Page 授業のシラバスとホームページ
• Rodney Van Meterのホームページ (home page)
• 村井研究室 Murai Lab