If a process is interrupted by a hardware interrupt (first-level interrupt handler), then the CPU scheduler becomes aware of this (for example, is the Scheduler runtime for hardware interrupts separate from the interrupted process)?
Details: I am trying to fix a problem in which the processor load in htop is too low for the given task of encrypting packets (the processor is less than 10% when encrypting packets at a speed of 400 Mbps; Raw encryption speed is only 1.6 Gbps, so encryption packets should not go faster than raw encryption speed).
Explanation: My hypothesis is that packet encapsulation occurs with hardware interrupts, which gives me the illusion of low CPU usage in htop. Typically, FLIHs are implemented in such a way that they complete their task as soon as possible and defer their work to SLIH (a second-level interrupt handler, which I assume is executed on behalf of ksoftirqd / X). But what happens if FLIH interrupts the process for a very long time? Does this mean some kind of OS jitter?
I am using Ubuntu 10.04.1 on x86-64 platform.
Additional debugging information:
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
The seventh (or sixth column of the column) here, I think, is the time spent inside the hardware interrupt handlers (htop uses this proc file to get statistics). I am wondering if this will end as a bug in Linux or the driver. When I took these / proc / stat snapshots, the traffic was at 500 Mbps and 500 Mbps.
source share