Measuring worst case interrupt processing time

All of lore.kernel.org
 help / color / mirror / Atom feed

* Measuring worst case interrupt processing time
@ 2013-12-08 13:18 Mohammed Riyaz
  2013-12-09  3:49 ` Andi Kleen
  2013-12-09 11:26 ` JJ Hiblot
  0 siblings, 2 replies; 6+ messages in thread
From: Mohammed Riyaz @ 2013-12-08 13:18 UTC (permalink / raw)
  To: linux-perf-users

Hi,

I am working on trying to measure the worst case processing time for
hard IRQ and soft IRQ. Well, I understand that we could use time
stamps at entry and exit to measure this. Just wanted to know if there
were other standard ways of measuring this. Any suggestions?

Thanks

Riyaz

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Measuring worst case interrupt processing time
  2013-12-08 13:18 Measuring worst case interrupt processing time Mohammed Riyaz
@ 2013-12-09  3:49 ` Andi Kleen
  2013-12-10  9:14   ` Mohammed Riyaz
  2013-12-09 11:26 ` JJ Hiblot
  1 sibling, 1 reply; 6+ messages in thread
From: Andi Kleen @ 2013-12-09  3:49 UTC (permalink / raw)
  To: Mohammed Riyaz; +Cc: linux-perf-users

Mohammed Riyaz <riyaz.list@gmail.com> writes:

> Hi,
>
> I am working on trying to measure the worst case processing time for
> hard IRQ and soft IRQ. Well, I understand that we could use time
> stamps at entry and exit to measure this. Just wanted to know if there
> were other standard ways of measuring this. Any suggestions?

If your goal is to identify worst case latencies of interrupted code --
ftrace has special tracers for this: CONFIG_{IRQSOFF,PREEMPT,SCHED}_TRACER

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Measuring worst case interrupt processing time
  2013-12-09  3:49 ` Andi Kleen
@ 2013-12-10  9:14   ` Mohammed Riyaz
  0 siblings, 0 replies; 6+ messages in thread
From: Mohammed Riyaz @ 2013-12-10  9:14 UTC (permalink / raw)
  To: Andi Kleen; +Cc: linux-perf-users

Hi Andi,

>
> If your goal is to identify worst case latencies of interrupted code --
> ftrace has special tracers for this: CONFIG_{IRQSOFF,PREEMPT,SCHED}_TRACER
>

ok, that got me thinking.. but it turns out that, the need is to
measure the processing time per IRQ. And of course, to then identify
the offenders using this.

Thanks
Riyaz

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Measuring worst case interrupt processing time
  2013-12-08 13:18 Measuring worst case interrupt processing time Mohammed Riyaz
  2013-12-09  3:49 ` Andi Kleen
@ 2013-12-09 11:26 ` JJ Hiblot
  2013-12-09 12:17   ` Mohammed Riyaz
  1 sibling, 1 reply; 6+ messages in thread
From: JJ Hiblot @ 2013-12-09 11:26 UTC (permalink / raw)
  To: Mohammed Riyaz, linux-perf-users

Hi,

I used to do this kind of measurement with a GPIO and an oscilloscope 
set up in persistence mode. In this case ,the precision of  the measure 
doesn't depend of the timer's resolution.

Jean-Jacques

Le 08/12/2013 14:18, Mohammed Riyaz a écrit :
> Hi,
>
> I am working on trying to measure the worst case processing time for
> hard IRQ and soft IRQ. Well, I understand that we could use time
> stamps at entry and exit to measure this. Just wanted to know if there
> were other standard ways of measuring this. Any suggestions?
>
> Thanks
>
> Riyaz
> --
> To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Measuring worst case interrupt processing time
  2013-12-09 11:26 ` JJ Hiblot
@ 2013-12-09 12:17   ` Mohammed Riyaz
  2013-12-09 16:53     ` Jean-Jacques Hiblot
  0 siblings, 1 reply; 6+ messages in thread
From: Mohammed Riyaz @ 2013-12-09 12:17 UTC (permalink / raw)
  To: JJ Hiblot; +Cc: linux-perf-users

On Mon, Dec 9, 2013 at 3:26 AM, JJ Hiblot <jjhiblot@gmail.com> wrote:
> I used to do this kind of measurement with a GPIO and an oscilloscope set up
> in persistence mode. In this case ,the precision of  the measure doesn't
> depend of the timer's resolution.

Though not suitable for my setup, never thought of using h/w for such
measurements. Interesting.

Thanks
Riyaz

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Measuring worst case interrupt processing time
  2013-12-09 12:17   ` Mohammed Riyaz
@ 2013-12-09 16:53     ` Jean-Jacques Hiblot
  0 siblings, 0 replies; 6+ messages in thread
From: Jean-Jacques Hiblot @ 2013-12-09 16:53 UTC (permalink / raw)
  To: Mohammed Riyaz; +Cc: linux-perf-users

I use that a lot in my day to day job.
Lately I've been toying with the idea of adding this kind of GPIO
debugging/profiling in the krpobe_events interface.
I'll post a draft when I've something working

Jean-Jacques

2013/12/9 Mohammed Riyaz <riyaz.list@gmail.com>:
> On Mon, Dec 9, 2013 at 3:26 AM, JJ Hiblot <jjhiblot@gmail.com> wrote:
>> I used to do this kind of measurement with a GPIO and an oscilloscope set up
>> in persistence mode. In this case ,the precision of  the measure doesn't
>> depend of the timer's resolution.
>
> Though not suitable for my setup, never thought of using h/w for such
> measurements. Interesting.
>
> Thanks
> Riyaz

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2013-12-10  9:14 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-12-08 13:18 Measuring worst case interrupt processing time Mohammed Riyaz
2013-12-09  3:49 ` Andi Kleen
2013-12-10  9:14   ` Mohammed Riyaz
2013-12-09 11:26 ` JJ Hiblot
2013-12-09 12:17   ` Mohammed Riyaz
2013-12-09 16:53     ` Jean-Jacques Hiblot

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.