Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1311542 > unrolled thread

Re: [RFC PATCH 2/2] sched: idle: IRQ based next prediction for idle period

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#1313318 — [RFC V2 0/2] IRQ based next prediction

The current approach to select an idle state is based on the idle period
statistics computation.

Useless to say this approach satisfied everyone as a solution to find the
best trade-off between the performances and the energy saving via the menu
governor.

However, the kernel is evolving to act pro-actively regarding the energy
constraints with the scheduler and the different power management subsystems
are not collaborating with the scheduler as the conductor of the decisions,
they all act independently.

The cpuidle governors are based on idle period statistics, without knowledge
of what woke up the cpu. In these sources of wakes up, the IPI are of course
accounted (as well as the timers irq) which results in doing statistics on
the scheduler behavior too. It is no sense to let the scheduler to take a
decision based on a next prediction of its own decisions.

In order to integrate the cpuidle framework into the scheduler, we have to
radically change the approach by clearly identifying what is causing a wake
up and how it behaves.

This serie inverts the logic.

Instead of tracking the idle durations and do statistics on them, these
patches track the interrupt individually and try to predict the next interrupt.

By combining the interrupts' next event on a single CPU, we can predict the
next event for the CPU, hence predict how long we will be sleeping when
entering idle.

The IPI and timer interrupts are not taken into account.

The first patch provides a callback to be registered in the irq subsystem
and to be called when an interrupt is handled with a timestamp.

The second patch uses the callback provided by the patch above to compute
the delta and store it in a circular buffer. It is per cpu, the callback
implements minimal operations as it is in an interrupt context.

When we the cpu enters idle, it asks for the expected sleep time. Then the
expected minimum sleep length for all interrupts is used and compared to
the timer sleep length, again the minimum is taken and gives the expected
sleep time.

The statistics are very trivial and could be improved later but this first
step shows we have a nice overall improvement in SMP. In UP the menu governor
is a bit better which may indicate the next prediction computation could be
improved but confirms removing the IPI from the equation increase the
accuracy.

Changelog:
	V2:
	   - Changed the register_ops approach for the irq subsystem
           - Fixed Nicolas's comments

Daniel Lezcano (2):
  irq: Add a framework to measure interrupt timings
  sched: idle: IRQ based next prediction for idle period

 drivers/cpuidle/Kconfig    |   9 +
 include/linux/interrupt.h  |  26 +++
 include/linux/irqhandler.h |   1 +
 kernel/irq/Kconfig         |   4 +
 kernel/irq/handle.c        |   1 +
 kernel/irq/internals.h     |  43 ++++
 kernel/irq/irqdesc.c       |   6 +
 kernel/irq/manage.c        |  10 +-
 kernel/sched/Makefile      |   1 +
 kernel/sched/idle-sched.c  | 529 +++++++++++++++++++++++++++++++++++++++++++++
 10 files changed, 629 insertions(+), 1 deletion(-)
 create mode 100644 kernel/sched/idle-sched.c

-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

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

The interrupt framework gives a lot of information and statistics about
each interrupt.

Unfortunately there is no way to measure when interrupts occur and provide
a mathematical model for their behavior which could help in predicting
their next occurence.

This framework allows for registering a callback function that is invoked
when an interrupt occurs. Each time, the callback will be called with the
timestamp.

The main objective is to track and detect the periodic interrupts in order
to predict the next event on a cpu and anticipate the sleeping time when
entering idle. This fine grain approach allows to simplify and rationalize
a wake up event prediction without IPIs interference, thus letting the
scheduler to be smarter with the wakeup IPIs regarding the idle period.

The irq timing feature must be enabled by the subsytem at compile time and
this one must use the DECLARE_IRQ_TIMINGS(ops) macro in order to declare
the ops to be used. Without this, the kernel will fail to compile with an
unresolved symbol. That is the guarantee the irq timings is not enabled
for nothing and will be used if it is defined in the config file.

Moreover, using a global ops variable, encapsulated in the irq code via the
DECLARE_IRQ_TIMINGS macro, allows to have the ops to be called at init
time, before the interrupts are setup. That prevents to introduce complex
code to update the subsystem's irq tracking table *after* the irqs init
happened.

The ops are as the following:
 - alloc   : called when an irqdesc is allocated
 - free    : called when an irqdesc is freed
 - setup   : called when an irq is registered with the irq handler
 - remove  : called when an irq is removed
 - handler : called when an irq was handled

A static key will be introduced when the irq prediction is switched on at
runtime in order to reduce an overhead near to zero when the kernel is not
using it.

Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
---
 include/linux/interrupt.h  | 26 ++++++++++++++++++++++++++
 include/linux/irqhandler.h |  1 +
 kernel/irq/Kconfig         |  4 ++++
 kernel/irq/handle.c        |  1 +
 kernel/irq/internals.h     | 43 +++++++++++++++++++++++++++++++++++++++++++
 kernel/irq/irqdesc.c       |  6 ++++++
 kernel/irq/manage.c        | 10 +++++++++-
 7 files changed, 90 insertions(+), 1 deletion(-)

diff --git a/include/linux/interrupt.h b/include/linux/interrupt.h
index ad16809..f7ff6fe 100644
--- a/include/linux/interrupt.h
+++ b/include/linux/interrupt.h
@@ -123,6 +123,32 @@ struct irqaction {
 	struct proc_dir_entry	*dir;
 } ____cacheline_internodealigned_in_smp;
 
+#ifdef CONFIG_IRQ_TIMINGS
+/**
+ * struct irqt_ops - structure to be used by the subsystem to track
+ *                   irq timings
+ * @alloc:    called when an irqdesc is allocated
+ * @free:     called when an irqdesc is free
+ * @setup:    called when an irq is setup, this is called under lock
+ * @remove:   called when an irq is removed
+ * @handler:  called when an interrupt is handled
+ */
+struct irqtimings_ops {
+	int (*alloc)(unsigned int);
+	void (*free)(unsigned int);
+	int (*setup)(unsigned int, struct irqaction *act);
+	void (*remove)(unsigned int, void *dev_id);
+	irqt_handler_t handler;
+};
+
+/**
+ * This macro *must* be used by the subsystem interested by the irq
+ * timing information.
+ */
+#define DECLARE_IRQ_TIMINGS(__ops)				\
+	const struct irqtimings_ops *__irqtimings = __ops;
+#endif
+
 extern irqreturn_t no_action(int cpl, void *dev_id);
 
 extern int __must_check
diff --git a/include/linux/irqhandler.h b/include/linux/irqhandler.h
index 661bed0..4c1c77e 100644
--- a/include/linux/irqhandler.h
+++ b/include/linux/irqhandler.h
@@ -10,5 +10,6 @@ struct irq_desc;
 struct irq_data;
 typedef	void (*irq_flow_handler_t)(struct irq_desc *desc);
 typedef	void (*irq_preflow_handler_t)(struct irq_data *data);
+typedef	void (*irqt_handler_t)(unsigned int, ktime_t, void *);
 
 #endif
diff --git a/kernel/irq/Kconfig b/kernel/irq/Kconfig
index 3b48dab..3f68619 100644
--- a/kernel/irq/Kconfig
+++ b/kernel/irq/Kconfig
@@ -77,6 +77,10 @@ config GENERIC_MSI_IRQ_DOMAIN
 config HANDLE_DOMAIN_IRQ
 	bool
 
+config IRQ_TIMINGS
+        bool
+	default n
+
 config IRQ_DOMAIN_DEBUG
 	bool "Expose hardware/virtual IRQ mapping via debugfs"
 	depends on IRQ_DOMAIN && DEBUG_FS
diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index a302cf9..cfc76fd 100644
--- a/kernel/irq/handle.c
+++ 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:
diff --git a/kernel/irq/internals.h b/kernel/irq/internals.h
index fcab63c..cd4f61a 100644
--- a/kernel/irq/internals.h
+++ b/kernel/irq/internals.h
@@ -20,6 +20,49 @@ extern bool noirqdebug;
 
 extern struct irqaction chained_action;
 
+#ifdef CONFIG_IRQ_TIMINGS
+
+extern const struct irqtimings_ops *__irqtimings;
+
+static inline int alloc_irqtiming(unsigned int irq)
+{
+	if (__irqtimings->alloc)
+		return __irqtimings->alloc(irq);
+	return 0;
+}
+
+static inline void free_irqtiming(unsigned int irq)
+{
+	if (__irqtimings->free)
+		__irqtimings->free(irq);
+}
+
+static inline int setup_irqtiming(unsigned int irq, struct irqaction *act)
+{
+	if (__irqtimings->setup)
+		return __irqtimings->setup(irq, act);
+	return 0;
+}
+
+static inline void remove_irqtiming(unsigned int irq, void *dev_id)
+{
+	if (__irqtimings->remove)
+		__irqtimings->remove(irq, dev_id);
+}
+
+static inline void handle_irqtiming(unsigned int irq, void *dev_id)
+{
+	if (__irqtimings->handler)
+		__irqtimings->handler(irq, ktime_get(), dev_id);
+}
+#else
+static inline int alloc_irqtiming(unsigned int irq) { return 0; }
+static inline int setup_irqtiming(unsigned int irq, void *dev_id) { return 0; }
+static inline void free_irqtiming(unsigned int irq) {}
+static inline void remove_irqtiming(unsigned int irq, void *dev_id) { }
+static inline void handle_irqtiming(unsigned int irq, void *dev_id) { }
+#endif
+
 /*
  * Bits used by threaded handlers:
  * IRQTF_RUNTHREAD - signals that the interrupt handler thread should run
diff --git a/kernel/irq/irqdesc.c b/kernel/irq/irqdesc.c
index 239e2ae..dc52f3a 100644
--- a/kernel/irq/irqdesc.c
+++ b/kernel/irq/irqdesc.c
@@ -157,6 +157,9 @@ static struct irq_desc *alloc_desc(int irq, int node, struct module *owner)
 	if (alloc_masks(desc, gfp, node))
 		goto err_kstat;
 
+	if (alloc_irqtiming(irq))
+		goto err_mask;
+
 	raw_spin_lock_init(&desc->lock);
 	lockdep_set_class(&desc->lock, &irq_desc_lock_class);
 
@@ -164,6 +167,8 @@ static struct irq_desc *alloc_desc(int irq, int node, struct module *owner)
 
 	return desc;
 
+err_mask:
+	free_masks(desc);
 err_kstat:
 	free_percpu(desc->kstat_irqs);
 err_desc:
@@ -187,6 +192,7 @@ static void free_desc(unsigned int irq)
 	delete_irq_desc(irq);
 	mutex_unlock(&sparse_irq_lock);
 
+	free_irqtiming(irq);
 	free_masks(desc);
 	free_percpu(desc->kstat_irqs);
 	kfree(desc);
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 6ead200..df1cdb6 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -1282,13 +1282,17 @@ __setup_irq(unsigned int irq, struct irq_desc *desc, struct irqaction *new)
 
 		init_waitqueue_head(&desc->wait_for_threads);
 
+		ret = setup_irqtiming(irq, new);
+		if (ret)
+			goto out_mask;
+
 		/* Setup the type (level, edge polarity) if configured: */
 		if (new->flags & IRQF_TRIGGER_MASK) {
 			ret = __irq_set_trigger(desc,
 						new->flags & IRQF_TRIGGER_MASK);
 
 			if (ret)
-				goto out_mask;
+				goto out_irqtiming;
 		}
 
 		desc->istate &= ~(IRQS_AUTODETECT | IRQS_SPURIOUS_DISABLED | \
@@ -1373,6 +1377,8 @@ mismatch:
 	}
 	ret = -EBUSY;
 
+out_irqtiming:
+	remove_irqtiming(irq, new->dev_id);
 out_mask:
 	raw_spin_unlock_irqrestore(&desc->lock, flags);
 	free_cpumask_var(mask);
@@ -1483,6 +1489,8 @@ static struct irqaction *__free_irq(unsigned int irq, void *dev_id)
 	/* Make sure it's not being used on another CPU: */
 	synchronize_irq(irq);
 
+	remove_irqtiming(irq, dev_id);
+
 #ifdef CONFIG_DEBUG_SHIRQ
 	/*
 	 * It's a shared IRQ -- the driver ought to be prepared for an IRQ
-- 
1.9.1

[toc] | [prev] | [next] | [standalone]

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

On Wed, 20 Jan 2016, Daniel Lezcano wrote:
> +#ifdef CONFIG_IRQ_TIMINGS
> +/**
> + * struct irqt_ops - structure to be used by the subsystem to track
> + *                   irq timings
> + * @alloc:    called when an irqdesc is allocated
> + * @free:     called when an irqdesc is free
> + * @setup:    called when an irq is setup, this is called under lock
> + * @remove:   called when an irq is removed
> + * @handler:  called when an interrupt is handled
> + */
> +struct irqtimings_ops {
> +	int (*alloc)(unsigned int);
> +	void (*free)(unsigned int);
> +	int (*setup)(unsigned int, struct irqaction *act);
> +	void (*remove)(unsigned int, void *dev_id);
> +	irqt_handler_t handler;
> +};
> +
> +/**
> + * This macro *must* be used by the subsystem interested by the irq
> + * timing information.
> + */
> +#define DECLARE_IRQ_TIMINGS(__ops)				\
> +	const struct irqtimings_ops *__irqtimings = __ops;
> +#endif

> @@ -20,6 +20,49 @@ extern bool noirqdebug;
>  
>  extern struct irqaction chained_action;
>  
> +#ifdef CONFIG_IRQ_TIMINGS
> +
> +extern const struct irqtimings_ops *__irqtimings;
> +
> +static inline int alloc_irqtiming(unsigned int irq)
> +{
> +	if (__irqtimings->alloc)
> +		return __irqtimings->alloc(irq);

I really have a hard time to understand that indirection. __irqtimings is
statically allocated and compiled in. There can be only one user for this in
the system ever and that user has all callbacks populated.

Why can't you spare all that pointer muck and simply have:

#ifdef CONFIG_IRQ_TIMINGS
int irqtiming_alloc(usigned int irq);
....
#else
static int irqtiming_alloc(usigned int irq) { return 0; }
...
#endif

and implement those functions in your idle thingy?

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

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

On 01/20/2016 06:55 PM, Thomas Gleixner wrote:
> On Wed, 20 Jan 2016, Daniel Lezcano wrote:
>> +#ifdef CONFIG_IRQ_TIMINGS
>> +/**
>> + * struct irqt_ops - structure to be used by the subsystem to track
>> + *                   irq timings
>> + * @alloc:    called when an irqdesc is allocated
>> + * @free:     called when an irqdesc is free
>> + * @setup:    called when an irq is setup, this is called under lock
>> + * @remove:   called when an irq is removed
>> + * @handler:  called when an interrupt is handled
>> + */
>> +struct irqtimings_ops {
>> +	int (*alloc)(unsigned int);
>> +	void (*free)(unsigned int);
>> +	int (*setup)(unsigned int, struct irqaction *act);
>> +	void (*remove)(unsigned int, void *dev_id);
>> +	irqt_handler_t handler;
>> +};
>> +
>> +/**
>> + * This macro *must* be used by the subsystem interested by the irq
>> + * timing information.
>> + */
>> +#define DECLARE_IRQ_TIMINGS(__ops)				\
>> +	const struct irqtimings_ops *__irqtimings = __ops;
>> +#endif
>
>> @@ -20,6 +20,49 @@ extern bool noirqdebug;
>>
>>   extern struct irqaction chained_action;
>>
>> +#ifdef CONFIG_IRQ_TIMINGS
>> +
>> +extern const struct irqtimings_ops *__irqtimings;
>> +
>> +static inline int alloc_irqtiming(unsigned int irq)
>> +{
>> +	if (__irqtimings->alloc)
>> +		return __irqtimings->alloc(irq);
>
> I really have a hard time to understand that indirection. __irqtimings is
> statically allocated and compiled in. There can be only one user for this in
> the system ever and that user has all callbacks populated.
>
> Why can't you spare all that pointer muck and simply have:
>
> #ifdef CONFIG_IRQ_TIMINGS
> int irqtiming_alloc(usigned int irq);
> ....
> #else
> static int irqtiming_alloc(usigned int irq) { return 0; }
> ...
> #endif
>
> and implement those functions in your idle thingy?

Hi Thomas,

yes sure, I can do something simpler.

Just to be sure, do you suggest to put the function declaration in 
kernel/irq/internal.h and the function definition in 
kernel/sched/idle-sched.c ?

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

[toc] | [prev] | [next] | [standalone]

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

On Thu, 21 Jan 2016, Daniel Lezcano wrote:
> Just to be sure, do you suggest to put the function declaration in
> kernel/irq/internal.h and the function definition in kernel/sched/idle-sched.c
> ?

Well obviously the declarations and stub functions should be in a header which
is accessible for both.

[toc] | [prev] | [next] | [standalone]

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

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.

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.

[toc] | [prev] | [next] | [standalone]

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

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

 

[toc] | [prev] | [next] | [standalone]

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

On Wed, 20 Jan 2016, 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 :)

Jiffies are not precise enough for some power states, even more so with 
HZ = 100 on many platforms.


Nicolas

[toc] | [prev] | [next] | [standalone]

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

On Wed, Jan 20, 2016 at 08:57:06PM +0100, Thomas Gleixner wrote:
> > 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.

The HPET thing, I just don't want to have to explain why this is so much
more expensive on some random weird machine, esp. since it really
doesn't matter.

[toc] | [prev] | [next] | [standalone]

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

On Wed, 20 Jan 2016, Peter Zijlstra wrote:

> On Wed, Jan 20, 2016 at 08:57:06PM +0100, Thomas Gleixner wrote:
> > > 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.
> 
> The HPET thing, I just don't want to have to explain why this is so much
> more expensive on some random weird machine, esp. since it really
> doesn't matter.

Fair enough.

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

On Thu, Jan 21, 2016 at 10:50:27AM +0100, Daniel Lezcano wrote:

> 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.

That certainly added to the confusion. But if you want per dev_id stats,
the whole alloc framework is 'broken' too, for it allocates the stuff
per irq.

> 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 ?

They're less common (thankfully) than they used to be, but I still have
them:

root@ivb-ep:~# cat /proc/interrupts | grep ","
  59:          0          0          0          0          0          0
  0          0          0          0          0          0          0
  0          0          0          0          0          0          0
  0          0          0          0          0          0          0
  0          0          0          0          0          0          0
  0          0          0          0          0          0   IO-APIC
  5-fasteoi   i801_smbus, i801_smbus

root@wsm-ep:~# cat /proc/interrupts | grep ","
 18:          0          0          0          0          0          0          0          0          0          0          0          0   IO-APIC  18-fasteoi   ehci_hcd:usb1, uhci_hcd:usb6
 19:    9695230   19577242   13205011    3970578     740376    1138693          0          0          0          0          0          0   IO-APIC  19-fasteoi   uhci_hcd:usb5, ata_piix
 23:          3          0          0          0        927          0          0          0          0          0          0          0   IO-APIC  23-fasteoi   ehci_hcd:usb2, uhci_hcd:usb4

root@snb:~# cat /proc/interrupts | grep ","
 19:   11058485          0          0          0          0          0          0          0   IO-APIC  19-fasteoi   ata_piix, ata_piix


Also there's a whole host of SOCs that has them.

[toc] | [prev] | [next] | [standalone]

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

On 01/21/2016 11:08 AM, Peter Zijlstra wrote:
> On Thu, Jan 21, 2016 at 10:50:27AM +0100, Daniel Lezcano wrote:
>
>> 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.
>
> That certainly added to the confusion. But if you want per dev_id stats,
> the whole alloc framework is 'broken' too, for it allocates the stuff
> per irq.

Yep, that's correct. I was planning to re-work it later by handling the 
shared interrupts, assuming they were not so common, but regarding the 
examples below, that's wrong.

>> 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 ?
>
> They're less common (thankfully) than they used to be, but I still have
> them:
>
> root@ivb-ep:~# cat /proc/interrupts | grep ","
>    59:          0          0          0          0          0          0
>    0          0          0          0          0          0          0
>    0          0          0          0          0          0          0
>    0          0          0          0          0          0          0
>    0          0          0          0          0          0          0
>    0          0          0          0          0          0   IO-APIC
>    5-fasteoi   i801_smbus, i801_smbus
>
> root@wsm-ep:~# cat /proc/interrupts | grep ","
>   18:          0          0          0          0          0          0          0          0          0          0          0          0   IO-APIC  18-fasteoi   ehci_hcd:usb1, uhci_hcd:usb6
>   19:    9695230   19577242   13205011    3970578     740376    1138693          0          0          0          0          0          0   IO-APIC  19-fasteoi   uhci_hcd:usb5, ata_piix
>   23:          3          0          0          0        927          0          0          0          0          0          0          0   IO-APIC  23-fasteoi   ehci_hcd:usb2, uhci_hcd:usb4
>
> root@snb:~# cat /proc/interrupts | grep ","
>   19:   11058485          0          0          0          0          0          0          0   IO-APIC  19-fasteoi   ata_piix, ata_piix
>
>
> Also there's a whole host of SOCs that has them.

Ah, I see. Thank you very much for these examples.

Sounds like, I have to handle the shared interrupts sooner than what I 
was expecting ... :)

   -- Daniel



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

[toc] | [prev] | [next] | [standalone]

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

On Thu, 21 Jan 2016, Peter Zijlstra wrote:
> On Thu, Jan 21, 2016 at 10:50:27AM +0100, Daniel Lezcano wrote:
> 
> > 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.
> 
> That certainly added to the confusion. But if you want per dev_id stats,
> the whole alloc framework is 'broken' too, for it allocates the stuff
> per irq.
> 
> > 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 ?
> 
> They're less common (thankfully) than they used to be, but I still have
> them:
> 
> root@ivb-ep:~# cat /proc/interrupts | grep ","
>   0   IO-APIC  5-fasteoi   i801_smbus, i801_smbus

Hardly something which is worth to add the extra complexity.
 
> root@wsm-ep:~# cat /proc/interrupts | grep ","
>  18:  0   0	 IO-APIC  18-fasteoi   ehci_hcd:usb1, uhci_hcd:usb6
>  23:  3   927  IO-APIC  23-fasteoi   ehci_hcd:usb2, uhci_hcd:usb4

Stick the USB thingy into the XHCI port :)

>  19:    9695230   19577242  .... IO-APIC  19-fasteoi   uhci_hcd:usb5, ata_piix
> root@snb:~# cat /proc/interrupts | grep ","
>  19:   11058485   IO-APIC  19-fasteoi   ata_piix, ata_piix

Go to the BIOS and enable AHCI mode. Both the snb and the wsm-ep chipsets can
be switched between legacy piix and ahci mode :)

You seem to have a faible for last century hardware.

> Also there's a whole host of SOCs that has them.

And one of the reasons is, that a lot of drivers do not support msi, while
these embedded beasts support MSI on almost every peripheral, at least the
newer ones.

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

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

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

[toc] | [prev] | [next] | [standalone]

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

On 01/21/2016 02:52 PM, Thomas Gleixner wrote:
> 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.

I just sent an email about how handling them :)

If the shared interrupts are only related to old hardware, these ones 
shouldn't have cpuidle, hence there is no need to enable the irq 
timings. So you are right in this case and we can keep the feature simple.

On a other hand, Peter sent three examples of /proc/interrupts with 
shared interrupts. I don't know how old are the platforms and what are 
they, but it seems the shared irq are still used.

At this point I have two contradictory information.

For the best of my knowledge, I am inclined to agree with you.

Peter can you give your opinion ?

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

[toc] | [prev] | [next] | [standalone]

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

On Thu, 21 Jan 2016, Daniel Lezcano wrote:
> On 01/21/2016 02:52 PM, Thomas Gleixner wrote:

> > 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.
> 
> If the shared interrupts are only related to old hardware, these ones
> shouldn't have cpuidle, hence there is no need to enable the irq timings. So
> you are right in this case and we can keep the feature simple.
> 
> On a other hand, Peter sent three examples of /proc/interrupts with shared
> interrupts. I don't know how old are the platforms and what are they, but it
> seems the shared irq are still used.

Well, its still there on x86 but slowly on the way out. What I meant with
legacy burden is, that the HW people finally got the idea that shared
interrupts are a horrible concept.

So we are seing them go away. My laptop (not the newest thingy) doesn't have
them anymore. Most devices use MSI now, except for the holdouts:

  0:         20          0          0          0   IO-APIC-edge      timer
  1:          1          1          5          3   IO-APIC-edge      i8042
  8:          5          6          0          4   IO-APIC-edge      rtc0
  9:        294       1231        118        318   IO-APIC-fasteoi   acpi
 12:         96       1748         55         76   IO-APIC-edge      i8042
 18:          0          0          0          0   IO-APIC  18-fasteoi   i801_smbus
 23:         11         12          8         51   IO-APIC  23-fasteoi   ehci_hcd:usb1

My latest server toy still has one shared entry:

   18-fasteoi   ehci_hcd:usb1, ehci_hcd:usb2, i801_smbus

which is just a complete braindamage on the hardware side. There are a
gazillion of free interrupt lines on that beast and of course they must route
3 devices to the same line.

We really should ignore that sillyness and if people complain, make them
complain to their HW vendor. That's the only way this crap will go away.

If we just keep on supporting this completely pointless nonsense the HW folks
will just not fix it.

We've been successful in the past to 'educate' hw people by making features
not available for mindless designs.

In this case we still support the feature, but it might be suboptimal. The
real interesting ports on that platform are MSI anyway, so I really couldn't
care less.

I have no idea how wide spread the shared nonsense is on the relevant ARM
platforms, but you might be able to figure that out faster than me.

Thanks,

	tglx

[toc] | [prev] | [next] | [standalone]

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

On Thu, Jan 21, 2016 at 07:56:36PM +0100, Thomas Gleixner wrote:

> We really should ignore that sillyness and if people complain, make them
> complain to their HW vendor. That's the only way this crap will go away.
> 
> If we just keep on supporting this completely pointless nonsense the HW folks
> will just not fix it.
> 
> We've been successful in the past to 'educate' hw people by making features
> not available for mindless designs.
> 
> In this case we still support the feature, but it might be suboptimal. The
> real interesting ports on that platform are MSI anyway, so I really couldn't
> care less.

I'm fine with not supporting shared interrupts, as long as the thing is
consistent.

[toc] | [prev] | [next] | [standalone]

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

On 01/20/2016 08:07 PM, 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.
>
> 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.

Indeed.



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

[toc] | [prev] | [next] | [standalone]

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

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;

This also looks completely busted for shared interrupts.

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.kernel

csiph-web