KEEP KERNEL + IRQ HANDLERS ON SEPARATE CPU

This is all hypothetical.  I just want to know what you all think.

Assume a dual-core or other multi-cpu environment.

In standard operating systems, when the user program wants a system service from the OS, it must make a system call that results in expensive context switching.  Same thing for interrupts, they also result in context switching.

In a multiple-CPU(core) environment, what if we dedicated one cpu to running OS and even let's say another cpu for processing IRQs.  That's it.  All tasks on CPU 0 are kernel tasks, all tasks on CPU 1 are IRQ handling taska, and user programs are relegated to CPU 2+.

Wouldn't this completely eliminate any latency of system calls and IRQs?  Has this already been done?  Would performance gains be better this way or just having all tasks distributed equally among all available CPUs?

>>9
From what I understand, interrupts are handled in this fashion:
  1. Device asserts IRQ
  2. CPU saves current state and enters IRQ handler
  3. Interrupt handler executes, which usually just brings device to non-interrupt state and saves whatever data to be processed by a DPC
  4. CPU restores state/exits IRQ handler
  5. DPC is executed which processes data gathered in step 3 and then makes data ready/issues signal (another interrupt) or whatever if needed

So, let's say for one device that requires one IRQ, why not have a process running on a dedicated CPU that does nothing else but PIO-style poll that particular device and then do step 5 when it has data ready.  This would eliminate steps 2 and 4, increasing performance.