On Mon, 21 Dec 1998, MOLNAR Ingo wrote:
>
> 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
>
>
As any good system person would say, "gimme some code, I'll beat on it."
Ought to be more fun that the original problems getting that ALR to boot,
if you remember that. :)
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
