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