Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings

[Daniel Lezcano]

On 01/20/2016 08:57 PM, Thomas Gleixner wrote:
> On Wed, 20 Jan 2016, Peter Zijlstra wrote:
>
> > On Wed, Jan 20, 2016 at 05:00:32PM +0100, Daniel Lezcano wrote:
> > > +++ b/kernel/irq/handle.c
> > > @@ -165,6 +165,7 @@ irqreturn_t handle_irq_event_percpu(struct irq_desc *desc)
> > >   			/* Fall through to add to randomness */
> > >   		case IRQ_HANDLED:
> > >   			flags |= action->flags;
> > > +			handle_irqtiming(irq, action->dev_id);
> > >   			break;
> > >
> > >   		default:
> >
> > > +++ b/kernel/irq/internals.h
> >
> > > +static inline void handle_irqtiming(unsigned int irq, void *dev_id)
> > > +{
> > > +	if (__irqtimings->handler)
> > > +		__irqtimings->handler(irq, ktime_get(), dev_id);
> > > +}
> >
> > Here too, ktime_get() is daft.
>
> What's the problem? ktime_xxx() itself or just the clock monotonic variant?
>
> On 99.9999% of the platforms ktime_get_mono_fast/raw_fast is not any slower
> than sched_clock(). The only case where sched_clock is faster is if your TSC
> is buggered and the box switches to HPET for timekeeping.
>
> But I wonder, whether this couldn't do with jiffies in the first place. If the
> interrupt comes faster than a jiffie then you hardly go into some interesting
> power state, but I might be wrong as usual :)
>
> > Also, you really want to take the timestamp _before_ we call the
> > handlers, not after, otherwise you mix in whatever variance exist in the
> > handler duration.
>
> 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.

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 ?



--
 <http://www.linaro.org/> Linaro.org â Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog