cp 命令中的上下文切换次数答案

【问题标题】：Number of context switches in cp commandcp 命令中的上下文切换次数
【发布时间】：2011-12-10 12:35:19
【问题描述】：

我试图了解 cp 命令与读/写组合的相似之处/不同之处在上下文切换方面。换句话说，使用 cp 从应用程序中复制数据相当于使用读/写组合。我认为读/写组合做了 4 个上下文切换 - 用户上下文 - 内核上下文（数据复制到内核缓冲区，然后数据复制到用户空间） - 用户上下文，用于读取，然后是另一组 2 个用于写入的上下文切换。 cp 会发生多少次上下文切换？零拷贝或发送文件也会更好比使用cp？

我在 linux 平台上使用 2.4 之后的内核。

谢谢。

【问题讨论】：

你似乎忘记了如何accept answers。
使用strace查看系统调用cp做了什么。
闻起来像过早优化。
正如@R.. 所说，过早优化。 IO 的瓶颈在于上下文切换之外的其他地方。您的进程很可能大部分时间都在等待，因为 IO 缓冲区已满。所以你会得到很多上下文切换信号等等。

标签： c linux linux-kernel system

【解决方案1】：

我从fileutils 4.1 检查了cp 的源代码，它通过循环调用read() 和write() 来复制常规文件。所以对于那个特定的cp，它和read/write 循环没有区别。

现在，对read() 和write() 的调用次数显然取决于用于复制的缓冲区的大小。

最后，很难看出上下文切换的数量是如何相关的，因为副本几乎肯定会受到 I/O 限制。如果它与您的特定情况相关，您可能需要详细说明它们是什么，以便我们能够解决这些情况。

【讨论】：

上下文切换很昂贵。我知道其中有多少人参与了读/写组合来传输文件。但想知道使用 cp 是否相同。因此，用户在最终到达目的地之前被转移了 4 次。这本质上意味着使用 sendfile 应该比 cp 更快。对吗？

【解决方案2】：

上下文切换也是异步发生的。特别是，对于每个系统时钟滴答（每 20 甚至 1 毫秒发生一次） - 因为那时内核会重新安排正在运行的任务。

我认为你不应该在 cp 进程中太关心它们。

你可以关心减少system calls的数量；对于文件副本，这意味着在调用 read 和 write 时需要更大的缓冲区

【讨论】：

【解决方案3】：

看看拼接：

【讨论】：