> The number of interrupt sources on a system ends up scaling this up to
> numerous IO-APIC RTE reprograms and ioapic_lock acquisitions per-second
> (granted, with a 5s timeout between reprogramming storms) where it
> competes against IO-APIC interrupt acknowledgements.
>
> Making the lock per- IO-APIC would at least put a bound on the number
> of competitors mutually interfering with each other, but a tighter
> bound on the amount of work than NR_IRQS would be more useful than that.
Ok there are 16 IOAPICs on an 8quad, but really if we start banging on
that lock someone is doing way too much hardware access...
Zwane
-- function.linuxpower.ca - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/