We have a HP DL980 running SuSE Linux Enterprise Server 11 sp2.

The machine hosts a PCIe digital IO card which is used to send a clock signal to sychronise with other machines.

If we do a top, one of the processes shows with the 'command' [irq/28-pci7230] and top shows this process is running on CPU8. We know pci7230 is the digital IO card. If I then cat /proc/interrupts, this shows all interrupts on CPU0.

Can some explain what is going on here? I was under the impression that the entry in top was showing that the interrupt is being handled by CPU8 but /proc/interrupts seems to suggest otherwise.

  • Do you have the irqbalance daemon running? – ewwhite Feb 14 '14 at 9:40

You're confusing the top half of the interrupt with the bottom half. It's perfectly normal for the top half of the interrupt to run on a different core from the bottom half. When a hardware interrupt occurs, you are in whatever context happened to be running. It's critical that you release that context as quickly as possible so that you aren't hijacking a random, possibly important, job.

"Linux (along with many other systems) resolves this problem by splitting the interrupt handler into two halves. The so-called top half is the routine that actually responds to the interrupt—the one you register with request_irq. The bottom half is a routine that is scheduled by the top half to be executed later, at a safer time. The big difference between the top-half handler and the bottom half is that all interrupts are enabled during execution of the bottom half—that's why it runs at a safer time. In the typical scenario, the top half saves device data to a device-specific buffer, schedules its bottom half, and exits: this operation is very fast. The bottom half then performs whatever other work is required, such as awakening processes, starting up another I/O operation, and so on. This setup permits the top half to service a new interrupt while the bottom half is still working." -- Top and Bottom halves

Interrupts themselves aren't scheduled -- an interrupt arrives when it arrives. The [irq/28-pci7230] kernel thread is scheduled to do the "real work".

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.