On Thu, 21 Jan 2016, Daniel Lezcano wrote:

On 01/20/2016 08:57 PM, Thomas Gleixner wrote:

quoted

That and we don't want to call it for each handler which returned handled.
The
called code would do two samples in a row for the same interrupt in case of
two shared handlers which get raised at the same time. Not very likely, but
possible.

Actually, the handle passes dev_id in order to let the irqtimings to sort out
a shared interrupt and prevent double sampling. In other words, for shared
interrupts, statistics should be per t-uple(irq , dev_id) but that is
something I did not implemented ATM.

So my comment about double sampling applies.

IMO, the handler is at the right place. The prediction code does not take care
of the shared interrupts yet.

I tried to find a platform with shared interrupts in the ones I have available
around me but I did not find any. Are the shared interrupts something used
nowadays or coming from legacy hardware ? What is the priority to handle the
shared interrupts in the prediction code ?

And why would that thing care about shared interruts at all? It's a legacy
burden and I really don't see a reason why that new thing which is targeted on
modern hardware should deal with them. Just treat them as a single interrupt
for now and be done with it.

Thanks,

	tglx