☰

计算机架构：USB 键盘是否由于 IRQ 范围窄而响应较慢？

tag-icon • tag-icon usb operating-systems irq
计算机架构：USB 键盘是否由于 IRQ 范围窄而响应较慢？

这是我刚刚想到的一个说法。有人能告诉我它是否正确以及为什么正确吗？

陈述： 由于 USB 键盘依赖于只能访问较低 IRQ 级别的 USB 通用驱动程序和架构，因此它无法让键盘像其他控制器（例如 PS2）那样以高优先级访问 IRQ。

这是否（如果是真的）意味着 USB 键盘的优先级（可用性而非速度）会比插在其他端口类型（如 PS2）上的键盘更低？

以一个映射到中等优先级 IRQ 的 USB 键盘为例，在一个卡在另一个中等优先级中断例程上的故障系统上。由于其优先级相对相等，键盘事件将被忽略，您将无法发送 Ctrl-Alt-del 或任何其他紧急按键。如果键盘具有更高的优先级，系统可以进入按键中断例程。

或者 USB 控制器是否具有足够的 IRQ 范围（无论是否具有连续优先级）以便为您的键盘提供所需的优先级（基本上低于电源故障）？

那么通过远程桌面会话上的网络连接映射的虚拟键盘怎么样？

编辑：我的问题与速度无关（见评论）：主要问题是：PS2 键盘是否更有机会与卡在中断优先级高于 USB 且低于键盘的某处的 CPU 对话？

答案1

这与 IRQ 范围无关，而是与三个主要因素有关：

  1. 公交车拥挤程度
  2. 数据量
  3. 数据路径的长度

过去，键盘和鼠标都有专用的 IRQ（IRQ1 用于键盘，IRQ12 用于 PS/2 鼠标）。

这意味着当按下一个键时，它几乎直接与 CPU 相连（通过 PIC；但仍然只有一次跳转）。这使得键盘事件可以在硬件中非常快速地处理，特别是因为它有 IRQ1。（当然，这完全是关于正常键盘使用，忽略从键盘控制器直接到 CPU 的复位线。）

另一方面，USB 设备都共享相同的总线和 USB 控制器的 IRQ（通常是与其他设备（如 NIC、视频卡等）共享的 IRQ 控制之一）。因此，对于 USB 键盘，事件从键盘控制器通过 USB 总线进入 USB 主机控制器，从那里进入辅助 PIC，然后进入主 PIC，然后进入操作系统或 BIOS 中的驱动程序，然后进入 CPU。此外，通过 USB 传输的数据中添加了错误检查数据。

换句话说，USB 键盘比 AT 或 PS/2 键盘需要处理的事情更多。数据路径更长，数据更多，甚至可能需要经过软件。即使 USB 带宽足够大，同一端口上还有其他设备也会导致冲突和延迟（您可以添加集线器，但其上的所有端口仍然是控制器上的同一端口）。因此需要等待更多时间。

此外，拥有自己的 (IRQ 意味着旧键盘可以在需要时中断 CPU 的处理。对于 USB，键盘没有这样的机制，只能发送一些数据并等待/希望 USB 控制器在某个时候中断 CPU。

虚拟键盘更糟糕，因为它们确实通过软件当然无法与硬件线路相竞争。

以下是 AT 或 PS/2 键盘与 USB 键盘之间区别的简单示意图：

在此处输入图片描述

答案2

简短回答

对于用户级代码，两种键盘的性能完全相同。可能会有细微的差别（纳米-到微-如果您编写设备驱动程序，则在现代 PC 上只需几秒即可完成。如果系统挂起，两个键盘都无法解决问题。请进行硬重启。

长答案 TL;DR;

什么是中断？

当硬件（或操作系统内部软件的某些关键部分，如内核）需要处理器服务时，它会触发一条消息或一个打断，请求处理器推迟正在执行的任何事情，并处理该请求。

怎么运行的？

当硬件产生中断（例如按键）时，该请求进入中断控制器。然后控制器立即在其机器代码的一行上中断 CPU（CPU 仍执行最后一行）。一旦处理器准备好处理此请求，它就会向中断控制器请求中断请求（IRQ）和一个处理程序。中断控制器有一个内部数据结构 -中断调度表其中包含一个指向 CPU 针对特定 IRQ 执行的例程的指针。

所有不同的中断都对应着明确定义的有限中断请求级别（IRQL）。例如，在 x86 系统上有 32 个 IRQL，而在 x64 和 IA64 上，IRQL 实际上更少 - 16 个。显然，硬件设备和软件服务的数量比 IRQL 多，这意味着所有一些系统对象都将共享 IRQL。

x64 的 IRQL 表

    IRQL | 描述
--------------------------------------------
    15 | 高调
    14 | 处理器间中断/电源
    13 | 时钟
    12 | 同步
    11 | 设备 N
    .. | ...
     3 | 设备 1
     2 | 调度/DPC
     1 | 装甲师
     0 | 被动/低

IRQL 越高（数字越大），优先级越高。系统的所有组件都试图将处理器的当前 IRQL 保持在尽可能低的级别 - 0。如果发生更高级别的中断，则处理器的当前 IRQL 级别会提高，并且直到所有更高级别的中断都得到解决后，才会处理较低级别的中断。如果 IRQ 调度程序能够将多个相同级别的 IRQ 排队以供处理器执行，则可以批量处理 IRQ。

这有什么意义呢？

这一切都经过精心设计，将最终用户与硬件的复杂性分开，并构建一个可以与多种类型的硬件/软件配合使用的通用架构。

  1. 仅当处理器处于被动/低（0）IRQL 时，才会执行用户级代码（即非内核级）。重点是，只有在处理完所有 IRQL 后，您才能在应用程序中处理按键事件。因此，对于键盘而言，分配给硬件中断的 IRQL 是什么并不重要。

  2. IRQL 只是操作系统的抽象，并不是一成不变的. 相应的 IRQ 和 IRQL 存储在 Windows 注册表中（例如），任何热心用户都可以手动更改它们。

结论

问题引述

由于 USB 键盘依赖于只能访问几个 IRQ 通道的 USB 通用驱动程序和架构，因此它无法让键盘像其他控制器（例如 PS2）那样以高优先级访问 IRQ。

也许作者的意思是降低 IRQL而不是更少的 IRQ 通道。无论如何，这并不重要，因为它在任何现代 PC 上对用户都是不可见的。可能的区别在于纳米-到微-秒级，并且只发生在内核级。在这两种情况下，用户级代码都被操作系统内核阻止。

这是否（如果这是真的）意味着 USB 键盘的响应速度会比插入其他端口类型的键盘更慢？

由于操作系统的设计方式，情况并非如此。如果操作系统忙于某事并且“速度慢”，则两个键盘的行为将完全相同。

举例来说，一个 USB 键盘映射到一个中等优先级的 IRQ，在一个故障系统上，该系统卡在另一个中等优先级的中断例程上

在这种情况下系统将出现 BSOD，IRQ 处理例程必须按照特定标准进行设计（例如它们必须快速、同步、非阻塞等）。任何偏离此标准的行为都会导致内核出现 BSOD。

由于其优先级相对相等，键盘事件将被忽略，您将无法发送 Ctrl-Alt-del 或任何其他紧急按键。

如果系统挂起，有很多事情可能会出错，但最有可能的是按键 IRQL 将在驱动程序级别处理。问题是，它不会被传递给订阅此类通知的应用程序，因为操作系统正忙于做其他事情。

相关内容