[ltt-dev] Questions related to statistics

Michel Dagenais michel.dagenais at polymtl.ca
Wed Jul 28 11:48:37 EDT 2010


> First question, in what process and mode are suppose to be the event
> after "process_exit" but before the change of process and are they
> suppose to count in cpu time?
> Ex:
> process_exit             # End of process
> page_free *
> send_signal                     # What process and mode? Count this in
> cpu time?
> sched_try_wakeup
> sched_schedule        # New process

The process when entering in process_exit is still executing but in 
system call. When coming out of that system call, it is waiting for 
exit, until its entry is removed from the process table by the operating 
system. The process may stay for some time in that zombie "waiting for 
exit" state if it awaits for some process to collect its return code.

> Second question, are the events between the "statedump_end" and the
> first next change of state (mode or process) suppose to count in the cpu
> time?
> statedump_end
> page_free
> page_free                    # Is this supposed to be included in cpu time.
> write
> syscall_exit           # Change of mode

On a single CPU, chances were that lttd was executing so it did not 
matter too much. Otherwise, once you know that a process is currently 
executing on a CPU, you can probably deduce that it was executing in 
this way since the trace start and count it properly in the statistics.

> Third question, in case of multiple cpu, should the difference from the
> last event received from the cpu be added to cpu time? Imagine two cpus.
> The first have it last event (fs.write, pid:134, mode:SYSCALL) at 110 ns
> and the second have it last event at 115 ns. Should we had 5 ns to the
> cpu time spent in process 134 and SYSCALL mode?

I dont understand the question. In my view, statistics are counted by 
thread and the two CPUs must be executing different threads. If the 
thread migrates from one CPU to the other, each slice before and after 
the migration will be counted separately.




More information about the lttng-dev mailing list