如果一个进程被硬件中断(第一级中断处理程序)中断，那么 CPU 调度程序是否意识到这一点(例如，调度程序是否独立于被中断的进程计算硬件中断的执行时间)？
更多详情: 我正在尝试解决以下问题:htop 中的 CPU 使用率对于指定的数据包加密任务而言太低(CPU 在 <10% 时以 400Mbps 的速度加密数据包；原始加密速度仅为 1.6Gbps，因此数据包加密不应进行任何操作比原始加密速度更快)。
解释: 我的假设是数据包封装发生在硬件中断时，因此给我一种 htop 中 CPU 使用率低的错觉。通常 FLIH 的实现是为了尽快完成他们的任务，并将他们的工作推迟到 SLIH(我猜是代表 ksoftirqd/X 执行的二级中断处理程序)。但是，如果 FLIH 中断进程很长时间会怎样？这会引入某种操作系统抖动吗？
我在 x86-64 平台上使用 Ubuntu 10.04.1。
其他调试信息:
while [ 1 ]; do cat /proc/stat | grep "cpu "; sleep 1; done;
cpu 288 1 1677 356408 1145 0 20863 0 0
cpu 288 1 1677 356772 1145 0 20899 0 0
cpu 288 1 1677 357108 1145 0 20968 0 0
cpu 288 1 1677 357392 1145 0 21083 0 0
cpu 288 1 1677 357620 1145 0 21259 0 0
cpu 288 1 1677 357972 1145 0 21310 0 0
cpu 288 1 1677 358289 1145 0 21398 0 0
cpu 288 1 1677 358517 1145 0 21525 0 0
cpu 288 1 1678 358838 1145 0 21652 0 0
cpu 289 1 1678 359141 1145 0 21704 0 0
cpu 289 1 1678 359563 1145 0 21729 0 0
cpu 290 1 1678 359886 1145 0 21758 0 0
cpu 290 1 1678 360296 1145 0 21801 0 0
这里的第七列(或第六列数字)我猜是在硬件中断处理程序中花费的时间(htop 使用此 proc 文件来获取统计信息)。我想知道这是否最终会成为 Linux 或驱动程序中的错误。当我拍摄这些/proc/stat 快照时，流量以 500Mbps 的输入和 500Mbps 的速度输出。
最佳答案
计算中断处理程序所花费的时间。
htop 以“si”(软中断)和“hi”(硬中断)显示。 ni 很好，wa 是 io-wait。
编辑: 来自 man proc:
第六列是硬件中断时间
第七列是softirq
八是偷来的时间
第十二是客人时间。
后两者只对虚拟化系统有意义。
您是否有使用 CONFIG_IRQ_TIME_ACCOUNTING(处理器类型和功能/细粒度任务级别 IRQ 时间统计)选项集构建的内核？
关于linux - Linux Scheduler 是否知道硬件中断(Scheduler Jitter)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/4753498/