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".
