Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'm trying to generate FTrace files inside an Android environment, using:

root@adroid:# echo 1 > /sys/kernel/debug/tracing/events/sched/sched_switch/enable
root@adroid:# echo 1 > /sys/kernel/debug/tracing/tracing_on
root@adroid:# cat /sys/kernel/debug/tracing/trace > mytracefile.txt
root@adroid:# echo 0 > /sys/kernel/debug/tracing/tracing_on
root@adroid:# echo 0 > /sys/kernel/debug/tracing/events/sched/sched_switch/enable

The problem is that in mytracefile.txt the precision of time stamp is in milliseconds:

          <idle>-0     [000] d.h7 14186.690000: sched_wakeup: comm=tfm_b6bcf800 pid=1714 prio=35 success=1 target_cpu=000
          <idle>-0     [000] d..3 14186.690000: sched_switch: prev_comm=swapper/0 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=tfm_b6bcf800 next_pid=1714 next_prio=35
    tfm_b6bcf800-1714  [000] d..3 14186.690000: sched_switch: prev_comm=tfm_b6bcf800 prev_pid=1714 prev_prio=35 prev_state=D|W ==> next_comm=swapper/0 next_pid=0 next_prio=120
          <idle>-0     [001] d.h3 14186.690000: sched_wakeup: comm=Player Aud Mixe pid=146 prio=35 success=1 target_cpu=001
          <idle>-0     [001] d..3 14186.690000: sched_switch: prev_comm=swapper/1 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=Player Aud Mixe next_pid=146 next_prio=35
 Player Aud Mixe-146   [001] d..3 14186.690000: sched_switch: prev_comm=Player Aud Mixe prev_pid=146 prev_prio=35 prev_state=D ==> next_comm=swapper/1 next_pid=0 next_prio=120
          <idle>-0     [001] d.h3 14186.690000: sched_wakeup: comm=Player Aud Mixe pid=146 prio=35 success=1 target_cpu=001
          <idle>-0     [001] d..3 14186.690000: sched_switch: prev_comm=swapper/1 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=Player Aud Mixe next_pid=146 next_prio=35
 Player Aud Mixe-146   [001] d..3 14186.690000: sched_switch: prev_comm=Player Aud Mixe prev_pid=146 prev_prio=35 prev_state=S ==> next_comm=swapper/1 next_pid=0 next_prio=120
          <idle>-0     [001] d.h3 14186.700000: sched_wakeup: comm=Player Aud Mixe pid=146 prio=35 success=1 target_cpu=001
          <idle>-0     [001] d..3 14186.700000: sched_switch: prev_comm=swapper/1 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=Player Aud Mixe next_pid=146 next_prio=35

Normally, it should be in the order of microseconds, like 14186.691234 instead of just 14186.690000.

I have already tested all the other trace_clock options that I have (local, global and counter) but the results are always the same. Changing that parameter doesn't change anything in the output file.

I followed carefully FTrace documentation but I don't know what else to change in configuration.

Searching over the internet I had only been able to find this bug report but it was not solved: http://lists.linaro.org/pipermail/linaro-dev/2011-February/002720.html

Any advice?

Are there additional modules in the kernel that I have to install?

  • Android Version: 4.2.2
  • Kernel Linux Version: 3.4.7

dmesg output is also showing milliseconds precision:

<4>[   38.130000] oom_adj 0 => oom_score_adj 0
<4>[   38.130000] oom_adj 1 => oom_score_adj 58
<4>[   38.140000] oom_adj 2 => oom_score_adj 117
<4>[   38.140000] oom_adj 4 => oom_score_adj 235
<4>[   38.150000] oom_adj 9 => oom_score_adj 529
<4>[   38.150000] oom_adj 15 => oom_score_adj 1000

Update:

We are building a graphic parser for android ftrace files (including atrace traces). That's why it is very important to have as much precision as possible.

Using the same device and other software tools we can successfully have microseconds precision.

So, now we're planning to edit ftrace.c source code to modify the way timestamp is generated to this one:

static inline uint64_t my_custom_jiffies(void)
{
         struct timeval tv;
         gettimeofday(&tv, NULL);
         return tv.tv_sec*1000000 + tv.tv_usec;
}

I personally think that is not a very good solution/architecture/implementation because this should be possible without modifying the source code... but it's the only idea that we have at this moment.

What do you think ?

share|improve this question
    
You listed a symptom as the problem. What is the issue this is causing? Like what are you workflow are you engaged in that that gets stopped by the lower precision? Are you trying to match times and several events land within the same second? Just something you noticed? etc. –  Joel Davis Jun 11 '13 at 12:16
5  
The kernel can't provide timers any more accurate than the underlying hardware supports. Do you know for a fact that your Android device provides a microsecond timer? There's a good chance it doesn't, on purpose, because that flies directly in the face of battery savings, one of the primary hardware design drivers for such devices. –  Warren Young Jun 11 '13 at 12:34
    
@WarrenYoung I'm seeing that the available clock options includes one ("uptime") denominated in jiffies, wouldn't that necessary give the OP more granularity (albeit granularity that varies depending on platform and not the level the OP may be going for)? I'm trying to understand the subject a little more. –  Joel Davis Jun 11 '13 at 13:57
2  
@JoelDavis, Jiffies are usually on the order of 1-10 mS. They are the original unit of the main PC periodic timer interrupt, which you define with the HZ kernel config. Higher resolution timers requires a special feature of the cpu, like the HPET. –  psusi Jun 11 '13 at 14:11
4  
@JoelDavis: You're still thinking at the Linux kernel API level. I want someone to point me to a datasheet for this phone/tablet/whatever SoC that shows me the hardware register containing the microsecond timer. –  Warren Young Jun 11 '13 at 15:01

1 Answer 1

up vote 0 down vote accepted

Apparently this issue has nothing to do with Android. We have tested with our custom Linux version and we have still the same problem: FTrace produces milliseconds precision while other tools are able to produce microseconds precision. Maybe a FTrace module version problem?

Regards,

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.