title: Is the Linux Scheduler aware of hardware interrupts (Scheduler Jitter)
body: <p>If a process is interrupted by a hardware interrupt (First Level Interrupt Handler), then does the CPU scheduler becomes aware of that (e.g. Does the Scheduler count execution time for hardware interrupts separately from interrupted process)?</p>
  
  <p>More details:
  I am trying to troubleshoot an issue where CPU utilization in htop is way too low for the specified packet encryption task (CPU is at &lt;10% while encrypting packets at 400Mbps; Raw encryption speed is only 1.6Gbps, so packet encryption should not go any faster than raw encryption speed). </p>
  
  <p>Explanation:
  My hypothesis is that packet encapsulation happens at hardware interrupts hence giving me the illusion of the low CPU usage in htop. Usually FLIHs are implemented so that they finish their task as quickly as possible and defer their work to SLIHs (Second Level Interrupt Handler which I guess is executed on behalf of ksoftirqd/X). But what happens if FLIH interrupts a process for a very long time? Does that introduce some kind of a OS jitter?</p>
  
  <p>I am using Ubuntu 10.04.1 on x86-64 platform.</p>
  
  <p>Additional debugging info:</p>
  
  <pre><code>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
  </code></pre>
  
  <p>Seventh (or sixth number column) column here I guess is the time spent inside Hardware interrupt handlers (htop uses this proc file to get statistics). I am wondering if this will end up as a bug in linux or the driver. When I took these /proc/stat snapshots the traffic was going at 500Mbps in and 500Mbps out.</p>