epoll - 为什么 ePoll 的扩展性比 Poll 更好？

Question

简短的问题，但对我来说很难理解。

为什么 ePoll 的扩展性比 Poll 更好？

Answer 1

poll 系统调用每次都需要将您的文件描述符列表复制到内核。这只会发生一次 epoll_ctl ，但不是每次都打电话epoll_wait .

另外，epoll_wait是 O(1)关于观察的描述符数量1，这意味着您等待一个描述符还是等待 5,000 或 50,000 个描述符都没有关系。 poll ，同时比 select 更有效率，仍然必须每次都遍历列表(即，就描述符数量而言，它是 O(N))。

最后，除了“正常”模式之外，epoll 还可以在“边缘触发”模式下工作，这意味着内核在您收到准备就绪信号后不需要跟踪您读取了多少数据。这种模式更难掌握，但效率更高。

1David Schwartz 正确指出，epoll_wait当然还是O(N)关于发生的事件。对于任何界面，几乎没有任何不同的方式。如果在一个被监视的描述符上发生了 N 个事件，那么应用程序需要获得 N 个通知，并且需要做 N 个“事情”以便对正在发生的事情使用react。
这在边缘触发模式中再次略有不同，但没有根本不同，您实际上会得到 M事件与 M <= N .在边缘触发模式下，当同一事件(例如， POLLIN )发生多次时，您收到的通知可能会更少，可能只有一个。但是，这对大 O 符号本身并没有太大改变。

然而，epoll_wait与观看的描述符数量无关。假设它以预期的“正常”方式使用(即许多描述符，很少事件)，这才是真正重要的，这里确实是 O(1) .

作为类比，您可以考虑哈希表。哈希表访问其在 O(1) 中的内容，但有人可能会争辩说，计算散列实际上是 O(N)关于 key 长度。这在技术上是绝对正确的，并且可能存在存在问题的情况，但是，对于大多数人来说，这并不重要。