将进程作为文件保存在 `/proc` 中如何不是性能问题？

Question

我知道“一切都是文件”并不完全正确，但据我所知，每个进程都会得到一个/proc包含大量文件的目录。读/写操作通常是速度的巨大瓶颈，并且必须一直从/向文件读/写会显着减慢处理速度。

是否必须将一堆文件保存在/proc缓慢的事情中？如果不是，那么在 Linux 中不必进行大量 IO 操作怎么不是一个巨大的设计缺陷？

Answer 1

文件完全动态地存在/proc和/sys存在，即当没有任何东西读取它们时，它们根本不存在并且内核不花时间生成它们。

您可以将/proc和/sys文件视为 API 调用。如果你不执行它们，内核就不会运行任何代码

Answer 2

我认为你正在接受整个“一切都是一个文件”的说法有点过于字面化。这真正意味着“一切都可以像文件一样被访问”。

尽管有些什么其他的答案可能会说了，事实上，没有在/proc实际存在的磁盘上的文件。该/proc文件系统不占用任何磁盘空间可言的，所以没有I / O都花在维护它。这可以通过卸载/proc文件系统并查看磁盘使用情况来确认。*

相反，它的内容是在程序尝试访问它时动态生成的。例如，当您键入 时ls /proc，实际发生的是内核从进程表中获取进程 ID 的当前列表并将它们发送到ls程序，就像它们是常规目录名称一样。同样的事情发生在每个“目录”的内容上，加上所有其他“目录”和/proc.

*在普通系统上，/proc文件系统可能会被使用，这将使您无法卸载它。因此，如果您真的想要执行此测试，您可能需要启动到单用户模式，即使这样也不能保证成功。

Answer 3

考虑/proc文件的另一种方式是，虽然“一切都是文件”，但并非每个文件都是存储在磁盘上的字节。

对于/proc文件，读取由内核根据运行进程的状态动态生成必要的字节来满足，而不是通过从磁盘存储中检索字节来满足。

同样，对/proc文件的写入（在允许的情况下）与内核交互，而不是与磁盘上的字节交互。

Answer 4

执行大量 I/O可能是一个瓶颈，尤其是在底层设备（例如硬盘）缓慢和/或繁忙的情况下。

然而，大多数部分proc实际上并不指物理设备。此外，proc包含系统中所有进程的表示。一些文件涉及数据，但其中大部分都驻留在 RAM 中——访问速度非常快。

事实上，访问文件可能会很慢。然而，仅仅维护目录树而不实际访问文件和目录并不会消耗太多性能。

还要记住，进程很少访问它们自己或其他进程在proc. 流程可以直接访问大多数信息，而无需proc手动访问。

示例：进程可以通过malloc. 内核知道进程已经分配了内存并通过/proc/…/maps. 该进程将通过访问指针直接使用内存，而不是通过对 进行 I/O /proc/…/mem。

Answer 5

术语“文件”在这里被重载了。它可能意味着存储在实际磁盘上的文件，但在这种情况下，它意味着使用文件 API 访问的任何内容：打开、读取、写入和关闭。

这四个函数是一个非常通用的 API，Unix 总是把各种其他的东西硬塞进这个 API 中。字符设备、块设备和命名管道都通过相同的四个基本函数进行访问，但被读取和写入的不是磁盘上的文件。

传统设备文件确实有在磁盘上的条目，以保持路径查找简单，但是这将对于是低效proc的sys文件系统，所以它们具有自定义查询过并且一点都不写东西到磁盘。就此而言，tmp文件系统也没有，它只是将数据保存在缓存中（并可能将它们交换到通用交换中）。

因此，当您不访问它们时，根本没有开销。当您这样做时，所需要的只是在内核中分配 dentry、inode 和文件结构（将文件描述符绑定到）并格式化来自内部内核结构的信息。它比专用 API 慢一点，但它避免了必须向内核添加更多入口点，并允许利用现有实用程序来处理信息。