gpt4 book ai didi

linux - Linux Scheduler 是否知道硬件中断(Scheduler Jitter)

转载 作者:IT王子 更新时间:2023-10-29 00:43:04 28 4
gpt4 key购买 nike

如果一个进程被硬件中断(第一级中断处理程序)中断,那么 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/

28 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com