c - 进程分叉后会发生什么？

Question

假设一个进程是从另一个进程派生出来的。换句话说，我们通过 fork 函数调用来复制一个进程。现在由于分叉是一种写时复制机制，所以每当分叉的进程或原始进程写入一个页面时，它们都会获得一个新的物理页面来写入。所以我的理解是，当分叉和原始进程都在执行时，事情就是这样的。

--> 分叉时，原始和分叉进程的所有页面都被授予只读访问权限，以便内核知道写入哪个页面。当这种情况发生时，内核将一个新的物理页面映射到写入进程，将以前的内容写入其中，然后授予对该页面的写入访问权限。现在我不清楚的是，如果分叉和原始进程都写入同一个页面，它们中的一个是否仍将保留原始物理页面（在分叉之前），或者两者都将获得新的物理页面。其次，我的假设是否正确，即分叉和原始进程中的所有页面在分叉时都被授予只读访问权限？

--> 现在由于每个页面错误都会触发一个中断，这意味着每次写入原始或分叉进程都会减慢执行速度。假设我们知道应用程序，并且我们知道将写入大量连续的内存页面，那么当组中的一个页面时，将写入权限授予多个页面（假设是一组页面）不是更好吗？被写入。这将减少由于页面错误处理而导致的中断数量。不是吗？当然，在这种情况下，我们有时可能会不必要地进行复制，但我认为中断比写入 512 个long类型的变量（每页 4096 字节）的开销要大得多。我的理解是正确的还是我遗漏了什么？

Answer 1

Fork 在语义上复制了一个进程。Copy-on-write 是一种优化，使它更快。优化通常有一些隐藏的权衡。有些情况会变得更快，但其他情况会受到影响。写时复制是有成本的，但我们希望通常会有所节省，因为大多数复制的页面实际上不会被孩子写入。在理想情况下，孩子执行立即执行。

因此，我们会遭受少量页面的页面错误异常，这比预先复制所有页面要便宜。

大多数“惰性求值”类型的优化都属于这种性质。

一百万个项目的惰性列表完全实例化比一百万个项目的常规列表更昂贵。但如果列表的消费者只访问前 100 个项目，则惰性列表获胜。

Answer 2

如果我没记错的话，其中一个进程将被视为首先写入页面。即使你有多个核心，我相信页面错误也会被串行处理。在这种情况下，第一个被捕获的进程会将两个进程的页面解耦，所以当第二个进程写入它时，不会有错误，因为它现在有一个可写的页面自己的。

我相信完成此操作后，现有页面由一个进程保留（并设置回读/写），并为另一个进程制作一个新副本。

我认为您的第三点围绕一个简单的点：“说如果我们知道应用程序......”。这就是问题所在：操作系统不知道应用程序。本质上，它“知道”的唯一事情将是间接的，通过内核编码人员的观察。他们无疑会观察到fork通常紧随其后的是exec，因此他们无疑会针对这种情况进行优化。是的，情况并非总是如此，而且您显然担心其他情况——我在这里要说的是它们足够不寻常，我猜想在它们上花费很少的精力。

我不太确定我是否遵循 4096 字节页面中大约 512 个长的逻辑或数学 -第一次写入页面时，它会在进程之间复制和解耦。从那时起，进一步写入该页面的任一进程的副本将不会导致任何进一步的页面错误（至少与写入时的副本有关——当然，如果进程站点空闲很长时间，则数据可能会被调出到页面文件，或按顺序排列的东西，但在这里无关紧要）。

Answer 3

好吧，如果 fork() 不使用 COW，初始成本会非常高。如果您查看典型的top显示，RSS/VSIZE 的比率非常小（例如，典型的 vi 会话为 2MB/56MB）。

克隆一个没有 COW 的进程会导致巨大的内存压力，这实际上会导致其他进程丢失它们的附加页面（必须将其移动到辅助存储，并且可能稍后恢复）。并且该分页实际上会导致每页 1-2 个磁盘 I/O（仅当页面是新的或脏的时才需要换出，只有当其他进程再次引用该页面时才需要换入）

Another point is granularity: back in the days, when MMU's did not exist, whole processes had to be swapped out to yield their memory, causing the system to actually freeze for a second or so. Page-faulting on a per-page basis causes more traps, but these are spread out nicely, allowing the processes to actually compete for physical ram. Without prior knowledge, it's hard to beat an LRU scheme.