---

前言

ref：http://ges.cs.wisc.edu/~remzi/OSTEP/Chinese

零散的记录知识，看《操作系统引论》

测量系统调用和上下文切换的成本

上下文切换需要多长时间？甚至系统调用要多长时间？如果感到好
奇，有一种称为 lmbench [MS96]的工具，可以准确衡量这些事情，并提供其他一些可能相关的性能指标。
随着时间的推移，结果有了很大的提高，大致跟上了处理器的性能提高。例如，1996 年在 200-MHz P6
CPU 上运行 Linux 1.3.37，系统调用花费了大约 4μs，上下文切换时间大约为 6μs[MS96]。现代系统的性能
几乎可以提高一个数量级，在具有 2 GHz 或 3 GHz 处理器的系统上的性能可以达到亚微秒级。

使用工具：Imbench

在这个作业中，你将测量系统调用和上下文切换的成本。测量系统调用的成本相对容易。

你必须考虑的一件事是时钟的精确性和准确性。你可以使用的典型时钟是 gettimeofday()。
详细信息请阅读手册页。你会看到，gettimeofday()返回自 1970 年以来的微秒时间。然而，
这并不意味着时钟精确到微秒。测量 gettimeofday()的连续调用，以了解时钟的精确度。这
会告诉你为了获得一个好的测量结果，需要让空系统调用测试的迭代运行多少次。如果
gettimeofday()对你来说不够精确，可以考虑利用 x86 机器提供的 rdtsc 指令。

测量上下文切换的成本有点棘手。lmbench 基准测试的实现方法，是在单个 CPU 上运
行两个进程并在它们之间设置两个 UNIX 管道。管道只是 UNIX 系统中的进程可以相互通
信的许多方式之一。第一个进程向第一个管道写入数据，然后等待第二个数据的读取。由
于看到第一个进程等待从第二个管道读取的内容，OS 将第一个进程置于阻塞状态，并切换
到另一个进程，该进程从第一个管道读取数据，然后写入第二个管理。当第二个进程再次
尝试从第一个管道读取时，它会阻塞，从而继续进行通信的往返循环。通过反复测量这种
通信的成本，lmbench 可以很好地估计上下文切换的成本。你可以尝试使用管道或其他通信
机制（例如 UNIX 套接字），重新创建类似的东西。
在具有多个 CPU 的系统中，测量上下文切换成本有一点困难。在这样的系统上，你需
要确保你的上下文切换进程处于同一个处理器上。幸运的是，大多数操作系统都会提供系
统调用，让一个进程绑定到特定的处理器。例如，在 Linux 上，sched_setaffinity()调用就是
你要查找的内容。通过确保两个进程位于同一个处理器上，你就能确保在测量操作系统停
止一个进程并在同一个 CPU 上恢复另一个进程的成本。

purify 和 valgrind

如你所见，有很多方法滥用内存。由于内存出错很常见，整个工具生态圈已经开发出来，可以帮助你在代码中找到这些问题。请查看 purify [HJ92]和 valgrind [SN05]，在帮助你找到与内存有关的问题的根源方面，两者都非常出色。一旦你习惯于使用这些强大的工具，就会想知道，没有它们时，你是如何活下来的。

[KR88]“The C Programming Language”Brian Kernighan and Dennis Ritchie Prentice-Hall 1988
C 之书，由 C 的开发者编写。读一遍，编一些程序，然后再读一遍，让它成为你的案头手册。
[N+07]“Exterminator: Automatically Correcting Memory Errors with High Probability”Gene Novark, Emery D.
Berger, and Benjamin G. Zorn
PLDI 2007
一篇很酷的文章，包含自动查找和纠正内存错误，以及 C 和 C ++程序中许多常见错误的概述。

x=x+3 的执行过程

计算机执行 x = x+3 的汇编过程