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

On Wed, 20 Jan 2016, Peter Zijlstra wrote:

quoted

On Wed, Jan 20, 2016 at 05:00:32PM +0100, Daniel Lezcano wrote:

quoted

+++ 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:

quoted

+++ b/kernel/irq/internals.h

quoted

+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 :)

quoted

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