Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1313481
| From | Thomas Gleixner <tglx@linutronix.de> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings |
| Date | 2016-01-20 21:00 +0100 |
| Message-ID | <qT759-2KF-25@gated-at.bofh.it> (permalink) |
| References | <qT3ux-vq-3@gated-at.bofh.it> <qT3uz-vq-41@gated-at.bofh.it> <qT6iK-2se-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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.
Thanks,
tglx
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: [RFC PATCH 2/2] sched: idle: IRQ based next prediction for idle period Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-18 14:30 +0100
Re: [RFC PATCH 2/2] sched: idle: IRQ based next prediction for idle period Thomas Gleixner <tglx@linutronix.de> - 2016-01-20 16:50 +0100
[RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-20 17:10 +0100
Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Nicolas Pitre <nicolas.pitre@linaro.org> - 2016-01-20 18:50 +0100
Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Peter Zijlstra <peterz@infradead.org> - 2016-01-20 19:50 +0100
Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-21 11:10 +0100
Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Peter Zijlstra <peterz@infradead.org> - 2016-01-20 20:10 +0100
Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Nicolas Pitre <nicolas.pitre@linaro.org> - 2016-01-20 20:20 +0100
Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Peter Zijlstra <peterz@infradead.org> - 2016-01-20 20:40 +0100
Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Peter Zijlstra <peterz@infradead.org> - 2016-01-20 20:40 +0100
Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Peter Zijlstra <peterz@infradead.org> - 2016-01-20 20:50 +0100
Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Nicolas Pitre <nicolas.pitre@linaro.org> - 2016-01-20 21:00 +0100
Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Peter Zijlstra <peterz@infradead.org> - 2016-01-20 21:30 +0100
Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Thomas Gleixner <tglx@linutronix.de> - 2016-01-20 21:00 +0100
Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-21 15:00 +0100
Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Thomas Gleixner <tglx@linutronix.de> - 2016-01-21 15:20 +0100
[RFC V2 0/2] IRQ based next prediction Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-20 17:10 +0100
[RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-20 17:10 +0100
Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Nicolas Pitre <nicolas.pitre@linaro.org> - 2016-01-20 21:20 +0100
Re: [RFC V2 2/2] sched: idle: IRQ based next prediction for idle period Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-21 14:10 +0100
[RFC V2 0/2] IRQ based next prediction Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-20 17:10 +0100
[RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-20 17:10 +0100
Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Thomas Gleixner <tglx@linutronix.de> - 2016-01-20 19:00 +0100
Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-21 10:30 +0100
Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Thomas Gleixner <tglx@linutronix.de> - 2016-01-21 11:30 +0100
Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Peter Zijlstra <peterz@infradead.org> - 2016-01-20 20:10 +0100
Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Thomas Gleixner <tglx@linutronix.de> - 2016-01-20 21:00 +0100
Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Nicolas Pitre <nicolas.pitre@linaro.org> - 2016-01-20 21:10 +0100
Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Peter Zijlstra <peterz@infradead.org> - 2016-01-20 21:30 +0100
Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Thomas Gleixner <tglx@linutronix.de> - 2016-01-20 21:30 +0100
Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-21 11:00 +0100
Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Peter Zijlstra <peterz@infradead.org> - 2016-01-21 11:10 +0100
Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-21 13:40 +0100
Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Thomas Gleixner <tglx@linutronix.de> - 2016-01-21 21:30 +0100
Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Thomas Gleixner <tglx@linutronix.de> - 2016-01-21 15:00 +0100
Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-21 15:20 +0100
Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Thomas Gleixner <tglx@linutronix.de> - 2016-01-21 20:00 +0100
Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Peter Zijlstra <peterz@infradead.org> - 2016-01-22 11:20 +0100
Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-21 10:30 +0100
Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Peter Zijlstra <peterz@infradead.org> - 2016-01-20 20:30 +0100
Re: [RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-21 11:00 +0100
[RFC V2 1/2] irq: Add a framework to measure interrupt timings Daniel Lezcano <daniel.lezcano@linaro.org> - 2016-01-20 17:10 +0100
csiph-web