Andrew Morton wrote:
> If a CPU take an interrupt while holding a contended spinlock,
> the cost of the interrupt is borne not only by the CPU which takes
> it, but also by all the CPUs which are waiting for the lock.
> So here's an x86 patch which disables cpu-local interrupts
> whenever that CPU is holding a spinlock.
> I don't have enough CPUs to measure its effects, but perhaps
> someone who has an 8-way may be interested in trying it with
> a lock- and interrupt-intensive workload, see what happens?
Too bad you can't set it up so that the interrupts are turned off on the
holders machine ONLY when the lock is contested. (A trick that, at the
very least, requires knowing which cpu holds the lock, not to mention
cross cpu control of the interrupt system.) Maybe a better way would be
to cause the APIC to direct the interrupt to a cpu that is not holding a
lock (like possibly the cpu that is spinning). This may be something
that could be done in the spin loop. Any other ideas, lets see, how
about taking the interrupt, noticing that a spin lock is held and
passing the interrupt to another cpu, or, possibly, queuing the
interrupt until the lock is released. But, we know some spin locks are
held for several ms....
Of all these, the one, IMHO, has the most promise is the spin
modification to redirect interrupts to the spinning cpu. The work is
all done by a cpu that is doing nothing else and the impact on the
holder of the lock is nil.
I think performance will be hit rather hard by this as the interrupt
off/on instructions are pipe line flushers. Doing this on every spin
lock will, I think, cause a real hit.
Real time sched: http://sourceforge.net/projects/rtsched/