我最近开始阅读Robert Love 的 Linux Kernel Development并且我很喜欢它！请阅读本书的以下摘录，以更好地理解我的问题：
一个数字标识中断，内核使用这个数字来执行一个特定的中断处理程序来处理和响应中断。例如，当您键入时，键盘控制器会发出一个中断，让系统知道键盘缓冲区中有新数据。内核记下传入中断的中断号并执行正确的中断处理程序。中断处理程序处理键盘数据并让键盘控制器知道它已准备好接收更多数据...
现在我在我的机器上进行了双启动，有时（事实上，很多）当我在 Windows 上输入一些东西时，我发现自己正在这样做，我称之为夜间爬虫模式。这是当我打字时，我在屏幕上看不到任何东西，过了一会儿，整个文本瞬间出现，可能缓冲区只是把所有东西都吐出来了。
现在我在 Linux 上看不到这种情况。是因为Linux 中存在中断上下文而 Windows 中没有它吗？
顺便说一句，我仍然不确定 Windows 中是否存在中断上下文，谷歌没有给我任何相关结果。
所有操作系统都有一个中断上下文，它是 CPU 架构的一个特性/约束——基本上，这就是计算机硬件的“工作方式”。但是，不同的操作系统（以及该操作系统中的驱动程序）在返回之前对中断的工作内容和工作量做出不同的选择。这可能与您的 Windows 体验有关，也可能与您的 Windows 体验无关。将按键转换为屏幕输出涉及大量代码，而中断处理只是一小部分。
一个数字标识中断，内核使用这个数字来执行一个特定的中断处理程序来处理和响应中断。例如，当您键入时，键盘控制器发出一个中断，让系统知道键盘缓冲区中有新数据。内核记下传入中断的中断号并执行正确的中断处理程序。中断处理程序处理键盘数据并让键盘控制器知道它已准备好接收更多数据
这是一个相当糟糕的描述。现在 USB 键盘的情况可能有所不同，但这似乎讨论了旧 PS/2 连接会发生什么，其中主板上的“8042”兼容芯片组通过 IRQ 线路向 CPU 发出信号，然后 CPU 执行任何代码位于存储在中断表中位置 9 中的地址（传统上是从物理内存中地址 0 开始的指针数组，尽管您可以从内存中更改地址，上次我玩这些东西时，PC 仍然有 <1MB RAM 和使用不同的内存布局模式）。
该调度过程与内核无关……这是硬件的工作方式。（可以要求键盘控制器不产生中断，从而允许操作系统/驱动程序软件定期“轮询”它以查看是否有新的事件数据可用，但真的使用它会很疯狂）。
尽管如此，中断表中的代码地址将指向内核或键盘驱动程序，内核/驱动程序代码将从键盘控制器的 I/O 端口读取键盘事件数据。对于这些硬件中断处理程序，主要目标是尽快从设备获取数据并将其存储到缓冲区中 - 既要确保从中断返回到正在发生的任何处理，又因为键盘控制器只能处理一次一个事件 - 需要在下一个事件之前将其读入缓冲区。
然后由操作系统/驱动程序向应用程序软件提供某种输入可用性信号，或者等待应用程序软件尝试读取更多键盘输入，但它可以以“只要你准备好”的方式进行。无论哪种方式，一旦应用程序有时间读取并开始响应输入，可能会发生一些事情，这意味着它需要非常长的时间：可能是额外的击键触发了一些复杂的重新分页算法，需要很长时间才能运行，或者击键导致程序执行已换出到磁盘的代码（检查维基百科的“虚拟内存”），在这种情况下，只有在硬盘将程序的一部分读入内存之后，程序可以继续运行。涉及窗口移动、图形剪辑算法等的此类边缘案例有数千个，这可能导致键盘处理代码需要很长时间才能完成，如果同时发生其他击键，键盘驱动程序会将它们读入该缓冲区，然后仅在慢速/阻塞处理完成后由应用程序“感知”。很可能所有击键后在缓冲区中的处理完成得更快：例如，如果程序的一部分从磁盘换入，则该部分可能准备好处理剩余的击键。将由键盘驱动程序读取到该缓冲区中，然后仅在慢速/阻塞处理完成后被应用程序“感知”。很可能所有击键后在缓冲区中的处理完成得更快：例如，如果程序的一部分从磁盘换入，则该部分可能准备好处理剩余的击键。将由键盘驱动程序读取到该缓冲区中，然后仅在慢速/阻塞处理完成后被应用程序“感知”。很可能所有击键后在缓冲区中的处理完成得更快：例如，如果程序的一部分从磁盘换入，则该部分可能准备好处理剩余的击键。
为什么 Linux 在这方面会比 Windows 做得更好？主要是因为操作系统、驱动程序和应用程序趋向于“更精简和更简陋”……更少的臃肿软件（如 C++ 与 C# .NET）、更少的内存浪费、更少的交换和延迟。