Skip to contentSkip to conversation

Ftrace Timer on OMAP3

DISCUSSION Thomas Klute 3 participants 4 messages May 25, 2012 – May 30, 2012

lore
Share & tools
lore
#0 lore raw

Hi everyone,

we're having some trouble getting useful results from Ftrace on OMAP3 (Gumstix Overo). As you can see in the example output below, function duration can't be displayed with a precision higher than about 30.5 us, which matches the frequency of the 32 kHz platform timer. For OMAP1, using OMAP_MPU_TIMER instead of CONFIG_OMAP_32K_TIMER should provide better results [1], but I couldn't find anything similar for OMAP3. Just setting CONFIG_OMAP_32K_TIMER=N didn't change the results. Did I miss anything, or isn't there any more precise timer?

Best regards,
Thomas Klute

[1]
http://elinux.org/images/0/0c/Bird-LS-2009-Measuring-function-duration-with-ftrace.pdf

Example Ftrace output:

  876.252136 |   0)               |  sys_sendmsg() {
  876.252166 |   0)               |    rom_rtadd() {
  876.252197 |   0)   0.000 us    |      release_queue_for_dst();
  876.252197 |   0)   0.000 us    |      add_route();
  876.252197 |   0) + 30.517 us   |    }
  876.252258 |   0) + 91.553 us   |  }
--
  876.311859 |   0)               |  sys_sendmsg() {
  876.311889 |   0)               |    rom_rtadd() {
  876.311889 |   0) + 30.518 us   |      release_queue_for_dst();
  876.311920 |   0)   0.000 us    |      add_route();
  876.311920 |   0) + 30.518 us   |    }
  876.311950 |   0) + 91.552 us   |  }
--
  876.371704 |   0)               |  sys_sendmsg() {
  876.371765 |   0)               |    rom_rtadd() {
  876.371765 |   0)   0.000 us    |      release_queue_for_dst();
  876.371765 |   0)   0.000 us    |      add_route();
  876.371795 |   0) + 30.517 us   |    }
  876.371826 |   0) ! 122.071 us  |  }
#1 lore raw
Quoted 11 lines · Thomas Klute

Hi everyone,

we're having some trouble getting useful results from Ftrace on OMAP3 (Gumstix Overo). As you can see in the example output below, function duration can't be displayed with a precision higher than about 30.5 us, which matches the frequency of the 32 kHz platform timer. For OMAP1, using OMAP_MPU_TIMER instead of CONFIG_OMAP_32K_TIMER should provide better results [1], but I couldn't find anything similar for OMAP3. Just setting CONFIG_OMAP_32K_TIMER=N didn't change the results. Did I miss anything, or isn't there any more precise timer?

I believe you are using mainline kernel here, if yes, you should be enabling the dmtimer using commandline argument, "clocksource="gp_timer".

Thanks,
Vaibhav

#2 lore raw
Quoted 13 lines · Vaibhav
Quoted 11 lines · Thomas Klute

Hi everyone,

we're having some trouble getting useful results from Ftrace on OMAP3 (Gumstix Overo). As you can see in the example output below, function duration can't be displayed with a precision higher than about 30.5 us, which matches the frequency of the 32 kHz platform timer. For OMAP1, using OMAP_MPU_TIMER instead of CONFIG_OMAP_32K_TIMER should provide better results [1], but I couldn't find anything similar for OMAP3. Just setting CONFIG_OMAP_32K_TIMER=N didn't change the results. Did I miss anything, or isn't there any more precise timer?

Quoted 2 lines

I believe you are using mainline kernel here, if yes, you should be enabling the dmtimer using commandline argument, "clocksource="gp_timer".

Also you need to pass 'nohlt' to kernel since gp_timer can't be kept when cpu is idled in deep state.

Thanks,
--
Ming Lei

#3 lore raw

Am 28.05.2012 10:24, schrieb Ming Lei:

Quoted 14 lines · Vaibhav
Quoted 13 lines · Thomas Klute
Quoted 11 lines

Hi everyone,

we're having some trouble getting useful results from Ftrace on OMAP3 (Gumstix Overo). As you can see in the example output below, function duration can't be displayed with a precision higher than about 30.5 us, which matches the frequency of the 32 kHz platform timer. For OMAP1, using OMAP_MPU_TIMER instead of CONFIG_OMAP_32K_TIMER should provide better results [1], but I couldn't find anything similar for OMAP3. Just setting CONFIG_OMAP_32K_TIMER=N didn't change the results. Did I miss anything, or isn't there any more precise timer?

Quoted 5 lines
Quoted 2 lines

I believe you are using mainline kernel here, if yes, you should be enabling the dmtimer using commandline argument, "clocksource="gp_timer".

Also you need to pass 'nohlt' to kernel since gp_timer can't be kept when cpu is idled in deep state.

I use the linux-omap tree, but adding "clocksource=gp_timer nohlt" to the kernel command line did the trick anyways. :-)

Thanks to both of you!
Thomas