On Thu, 21 Jan 2016, Daniel Lezcano wrote:
> On 01/20/2016 08:57 PM, Thomas Gleixner wrote:
> > 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
