Cc: Eric W. Biederman <ebiederm@...>, Olaf Dabrunz <od@...>, Thomas Gleixner <tglx@...>, Ingo Molnar <mingo@...>, H. Peter Anvin <hpa@...>, <linux-kernel@...>
On Wed, 2008-06-04 at 13:33 +0200, Stefan Assmann wrote:
Usually, it's a *really* ugly combo of devices too. The symptom to this
problem was a large number of test systems that would fall over under
heavy IO after some time. I spent many weeks at the end of last year
trawling through the qla2xxx, megaraid/megasas, and other drivers
looking for the "problem", we even shipped some systems to some of these
hardware folks so they could hook up bus analyzers to see if the
interrupts really were being generated, and a lot more fun.
In the end, because I didn't have the level of information about the
unfortunate implementation of some of these chipsets, I reworked a patch
from Thomas that handles mask/unmask vs. edge->level->edge transition
depending upon PCI quirks for known at-issue bridges. I've been hoping
someone would dig up enough information to actually disable these
horrible "features" so we can get that upstream and into RT.
Meanwhile, I think this really shows that a couple of us who've been
meaning to poke at per-device IRQs should do so once again. This is the
real solution - kill off all those per-IRQ threads, have one per device
and split each IRQ into a "top" and "bottom" (just kidding on the names)
half. Have the first part be *incredibly* small and just return if the
device actually was responsible for the IRQ (and quiesse it), and have
the second part do the heavyweight handling. Since the second part can
run as a thread (and actually sleep for however long, because it's now
per device) - and since we have threaded tasklets and all this on RT
anyway - we can just kill off most of the extra logic in many Linux
interrupt handlers and have just the interrupt thread do the work.
Anyway, that's the bluesky idea (and rejected OLS 2008 paper :P)...
Jon.
--
