From mboxrd@z Thu Jan  1 00:00:00 1970
From: pierre-marc.fournier@polymtl.ca (Pierre-Marc Fournier)
Date: Fri, 17 Oct 2008 11:26:53 -0400
Subject: [ltt-dev] sys time
In-Reply-To: <8d94e9280810170606o729767f3p839c1c3a59c9565d@mail.gmail.com>
References: <8d94e9280810170558j5b9ed8d1q7da37da677c7bf7d@mail.gmail.com>
	<8d94e9280810170606o729767f3p839c1c3a59c9565d@mail.gmail.com>
Message-ID: <48F8AEBD.2030303@polymtl.ca>

Gian Lorenzo Meocci wrote:

> I want to know if it is possible to obtain this results using lttng trace.

It is definitely possible.

> Actually I made a sum of all differences from a
> kernel_arch_trap_entry/kernel_arch_trap_exit,
> kernel_arch_syscall_entry/exit, kernel_softirq_entry/exit,
> mm_handle_fault_entry/exit, kernel_irq_entry/exit.

You don't need mm_handle_fault_entry/exit because they are always
enclosed within kernel_arch_trap_entry/exit's.

> But for now, my results isn't very good.

- You need to stop counting time when your process is being scheduled
out. See the kernel_sched_schedule events.

- You need to filter the events based on the pid of the process you're
investigating, but I guess you're already doing that.

- If the process is being created inside the trace, you need to start
counting time only after it is created, of course. You could count
syscall time starting at the kernel_process_fork that creates the
process. Also, you need to stop counting time when it's destroyed of course.

- If the process already exists when the trace is started, only consider
events after the list_statedump_end event. Before that, the pid of each
event might not be reliable.

pmf