Linux Scheduler是否知道硬件中断(调度程序抖动)

概述如果进程被硬件中断(第一级中断处理程序)中断,那么CPU调度程序是否会意识到这一点(例如,调度程序是否将硬件中断的执行时间与中断进程分开计算)？ 更多细节： 我正在尝试解决htop中的CPU利用率对于指定的数据包加密任务来说太低的问题(CPU在400Mbps加密数据包时<10％;原始加密速度仅为1.6Gbps,因此数据包加密不应该去任何比原始加密速度更快的速度). 说明： 我的假设是数据包封装发生 如果进程被硬件中断(第一级中断处理程序)中断,那么cpu调度程序是否会意识到这一点(例如,调度程序是否将硬件中断的执行时间与中断进程分开计算)？

更多细节：
我正在尝试解决htop中的cpu利用率对于指定的数据包加密任务来说太低的问题(cpu在400Mbps加密数据包时<10％;原始加密速度仅为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 0cpu  288 1 1677 356772 1145 0 20899 0 0cpu  288 1 1677 357108 1145 0 20968 0 0cpu  288 1 1677 357392 1145 0 21083 0 0cpu  288 1 1677 357620 1145 0 21259 0 0cpu  288 1 1677 357972 1145 0 21310 0 0cpu  288 1 1677 358289 1145 0 21398 0 0cpu  288 1 1677 358517 1145 0 21525 0 0cpu  288 1 1678 358838 1145 0 21652 0 0cpu  289 1 1678 359141 1145 0 21704 0 0cpu  289 1 1678 359563 1145 0 21729 0 0cpu  290 1 1678 359886 1145 0 21758 0 0cpu  290 1 1678 360296 1145 0 21801 0 0

这里的第七(或第六个数字列)列我想是在硬件中断处理程序中花费的时间(htop使用此proc文件来获取统计信息).我想知道这是否会最终成为linux或驱动程序中的错误.当我使用这些/ proc / stat快照时,流量以500Mbps和500Mbps输出.

解决方法 在中断处理程序中花费的时间被计算在内.

htop以“si”(软中断)和“hi”(硬中断)显示.你很好,我很等待.

编辑：
来自man proc：

第六列是硬件irq时间

第七栏是softirq

八是被偷的时间

nIEnth是客人的时间.

后两者仅对虚拟化系统有意义.

您是否拥有使用CONfig_IRQ_TIME_ACCOUNTING(处理器类型和功能/精细粒度任务级别IRQ时间记帐)选项集构建的内核？

总结

以上是内存溢出为你收集整理的Linux Scheduler是否知道硬件中断(调度程序抖动)全部内容，希望文章能够帮你解决Linux Scheduler是否知道硬件中断(调度程序抖动)所遇到的程序开发问题。

如果觉得内存溢出网站内容还不错，欢迎将内存溢出网站推荐给程序员好友。