[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160422182146.GC3974@linaro.org>
Date: Fri, 22 Apr 2016 20:21:46 +0200
From: Daniel Lezcano <daniel.lezcano@...aro.org>
To: tglx@...utronix.de
Cc: nicolas.pitre@...aro.org, shreyas@...ux.vnet.ibm.com,
linux-kernel@...r.kernel.org, peterz@...radead.org,
rafael@...nel.org, vincent.guittot@...aro.org
Subject: Re: [PATCH V4] irq: Track the interrupt timings
On Wed, Apr 13, 2016 at 01:05:56PM +0200, Daniel Lezcano wrote:
> The interrupt framework gives a lot of information about each interrupt.
>
> It does not keep track of when those interrupts occur though.
>
> This patch provides a mean to record the elapsed time between successive
> interrupt occurrences in a per-IRQ per-CPU circular buffer to help with the
> prediction of the next occurrence using a statistical model.
>
> A new function is added to browse the different interrupts and retrieve the
> timing information stored in it.
>
> A static key is introduced so when the irq prediction is switched off at
> runtime, we can reduce the overhead near to zero. The irq timings is
> supposed to be potentially used by different sub-systems and for this reason
> the static key is a ref counter, so when the last use releases the irq
> timings that will result on the effective deactivation of the irq measurement.
>
> Signed-off-by: Daniel Lezcano <daniel.lezcano@...aro.org>
> Acked-by: Nicolas Pitre <nicolas.pitre@...aro.org>
> ---
> V4:
> - Added a static key
> - Added more comments for irq_timings_get_next()
> - Unified some function names to be prefixed by 'irq_timings_...'
> - Fixed a rebase error
> V3:
> - Replaced ktime_get() by local_clock()
> - Shared irq are not handled
> - Simplified code by adding the timing in the irqdesc struct
> - Added a function to browse the irq timings
> V2:
> - Fixed kerneldoc comment
> - Removed data field from the struct irq timing
> - Changed the lock section comment
> - Removed semi-colon style with empty stub
> - Replaced macro by static inline
> - Fixed static functions declaration
> RFC:
> - initial posting
> ---
Hi Thomas,
do you think this patch is acceptable ?
Powered by blists - more mailing lists