0

I am using Perf to detect the number and locations of DRAM accesses in a workload. For locations, I need to trace in sampling mode. Therefore, I trace in sampling mode, and in order to get the total number of accesses, I multiply the number of access events by the sampling period (i.e., the number of instructions between each sample) .

I also need the total time the application is on the CPU. In other words, I need a value similar to what is reported by top. Because I need to know the idle period (during which the application is also on the CPU) between each DRAM access in this single application. This is not reported in sampling mode and I can not use both modes (i.e., both perf record and perf stat) at the same time. Is there any mechanism to achieve this?

TheAhmad
  • 810
  • 1
  • 9
  • 21
  • 1
    Record a separate event like `task-clock`, and look at the total for it maybe? I don't think you'll get good results extrapolating time from L3 miss samples. But if you actually want to know the times between L3-miss events, I think each event should be timestamped. – Peter Cordes May 08 '20 at 16:21
  • Thanks @PeterCordes. I want only the DRAM idle time during which the process is **on** the processor. In other words, the time period when the processor is *Idle* or is running some *other process* is not intended. I edited the question. – TheAhmad May 08 '20 at 19:45
  • Ok, so that rules out just using timestamps on the existing events I guess? `task-clock` only counts when a thread of a task is active on a core. – Peter Cordes May 08 '20 at 19:46
  • Sorry, @PeterCordes. You mean that I should sample two events (`L3-misses` and `task-clock`), simultaneously? If `task-clock` accounts for the time of a process on the processor, then it is OK. Then I should multiply the number of samples by the period (i.e., the number of events between successive samples), right? – TheAhmad May 08 '20 at 20:26
  • 1
    I'm not sure how easily you can get `perf report` to show you what you want to know; what you really want is `perf stat -e task-clock` alongside your samples from `perf record` for L3-misses. But yes, the kernel does track when it schedules / deschedules a task so the info of exactly how many CPU-nanoseconds a process has been running for is there somewhere. It's just a matter of getting that recorded somehow. – Peter Cordes May 08 '20 at 20:29
  • Can I use `Ftrace` with something like `echo 1 > /sys/kernel/debug/tracing/events/sched/sched_stat_runtime/enable` besides `Perf`? – TheAhmad May 08 '20 at 22:34

1 Answers1

0

Ftrace dump is huge. It dumps logs for every process, while I only need information for my program and its threads. Ftrace filter can only work on PIDs. But I need process names (a.k.a, comms). So this is the best that I could do without recompiling the kernel.

I used Systemtap with the following script:

sudo stap -e 'probe scheduler.process_exit {if (execname() == "evince"){printf("%s, %lu\n", execname(), task_current()->se->sum_exec_runtime)}}'

scheduler.process_exit() is a probe point from the Systemtap tapset library, that internally hooks the do_exit() kernel function (I used the former because it seems more portable). execname() returns the process name and task_current() returns the task for the current context. se (a schedulable entity for the scheduler) is a field in task_struct (data structure associated with a process or thread in Linux) and sum_exec_runtime shows the total physical runtime of the schedulable entity.

So, this is what the script does:

At each process (or thread) exit, it checks if the name of the process (or thread) is evince. If this is the case, the total execution time (in nanoseconds) of evince will be displayed (because we are in the context of the evince process before exit).

Obviously, this is not the most portable solution.

TheAhmad
  • 810
  • 1
  • 9
  • 21