什么时候轮询比中断好？答案

【问题标题】：when polling is better than interrupt?什么时候轮询比中断好？
【发布时间】：2013-05-20 07:57:18
【问题描述】：

我在看这张照片：

并有两个问题： 1. 磁盘应该快多少才能通过中断引用轮询？

我认为这是因为 ISR 和进程跳转（使用中断时） - 例如，在使用快速 SSD 时轮询会更好，其中轮询所需的时间比中断（ISR+调度程序）要短。我弄错了吗？

第二个问题是：如果我的磁盘在第一个问题中比 SSD 慢，但仍然很快 - 是否有任何理由更喜欢轮询？

我想知道我将有很多 I/O 读取请求这一事实是否足以让我更喜欢轮询。

谢谢！

【问题讨论】：

我只能笼统地说，但现在大多数设备都不会产生那么多中断，它们会排队来自驱动程序的请求，自己完成大部分逻辑并且仅在完成时产生中断一个或多个请求。除非您在谈论嵌入式系统，否则轮询很少有意义。
如果它回答了您的问题，请不要忘记接受我的回复！谢谢。

标签： io operating-system interrupt polling

【解决方案1】：

您可以想象一种情况，运行中断处理程序（使缓存无效，设置要运行的中断堆栈）的开销可能比实际执行读取或写入要慢，在这种情况下，我猜轮询会更快。

不过，SSD 的速度比磁盘快，但仍比内存慢得多。 SSD 仍然需要几十微秒到几毫秒才能完成每个 I/O，而进行中断设置和拆卸会使用所有内存中的操作，并且可能最多需要 100-1000 个周期（约 100ns 到 1us）。

使用中断而不是轮询的主要好处是使用中断的“禁用”效果要低得多，因为您不必安排 I/O 线程在没有可用数据时连续轮询更多数据.它的另一个好处是立即处理 I/O，因此如果用户键入一个键，则在调度 I/O 线程时字母出现在屏幕上之前不会有暂停。将这些问题结合起来是一团糟——在 I/O 线程中插入任意停顿会降低轮询的资源密集度，但会以更慢的响应时间为代价。这些可能是没有人在内核 I/O 设计中使用轮询的主要原因。

从用户进程的角度来看（使用软件中断系统，如 Unix 信号），任何一种方式都是有意义的，因为轮询通常意味着阻塞系统调用，例如 read() 或 select()，而不是（比如说）检查布尔内存-mapped 变量或发出设备指令，如内核版本的轮询可能会这样做。在操作系统中让系统调用为我们完成这项工作可能对性能有益，因为用户态线程不会通过使用信号而不是任何其他系统调用来或多或少地使其缓存失效。然而，这非常依赖于操作系统，因此分析是确定哪个代码路径更快的最佳选择。

【讨论】：

虽然不完全正确，但我想更新它（在获得 7 年更多经验之后：-P）。中断的主要延迟问题是线程跳数，这通常会在您的 IO 路径中增加数十微秒。因此，如果您使用读取延迟低至 20us 且写入延迟低至 150us 的 SSD，假设您只执行一个线程跃点，则读取延迟可能会降低 2 倍/写入延迟会降低 15%。还有更新、更快的设备，如 3dXpoint，其延迟更低。因此，实际上几乎所有低延迟块存储产品现在都在某些时候使用轮询。
此外，许多使用固定用户空间线程来执行 IO，以避免内核和用户空间之间的上下文切换（并避免必须在内核中构建所有内容）。