On Mon, 21 Dec 1998, Robert M. Hyatt wrote:
> IE on our old sequent we had, the interrupt controller was aware of what
> each cpu was doing (process priority of whatever was running on a per cpu
> basis) and it would channel interrupts to idle processors. I suppose we
> could dynamically reprogram the APIC to direct interrupts away from a CPU
> that is busy, so long as one is idle. But the question is, is this worth
> anything other than from a purely theoretical interest point of view?
yes this is doable, but there is a limitation with the CPU's 'priority'
field in the APIC architecture: it's basically an interrupt priviledge
level. So it seems we can only 'tune' per-CPU priorities by also shutting
off IRQ sources completely, not good and race-prone. So currently we set
all priorities equal. (But in 2.3 we definitely want to re-examine the
hardware's possibilities of routing IRQs more dynamically.)
but the interactiveness thing is completely independent of this, it's
basically the act of bringing an IRQ event together with a woken up
process as fast as possible, even if the IRQ happens to hit a busy CPU.
This is what reschedule_idle() does. Note that the implementation can not
only distinct between 'idle and busy' but between various per-process
priorities too, giving much finer control over reschedules. It's basically
a framework for doing reschedules on any CPU, from whatever other CPU, by
sending point-to-point IPIs (inter-CPU-interrupts). Currently it deals
with idle CPUs only, but as current patches have shown, it can easily be
extended to implement arbitrary SMP rescheduling logic.
-- mingo
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
