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.
_______________________________________________ ltt-dev mailing list [email protected] http://lists.casi.polymtl.ca/cgi-bin/mailman/listinfo/ltt-dev
