On 9/19/14, 8:47 AM, Arnaldo Carvalho de Melo wrote:
Now that the need for getting a backtrace from existing threads, a-la
using ptrace via gdb to attach to it and then traverse its stack to
provide that backtrace, I think we need to do something on the perf
infrastructure in the kernel to do that, i.e. somehow signal the perf
kernel part that we want a backtrace for some specific thread.
Not at event time, but at some arbitrary time, be it creating an event
that, as you suggested, will create a timer and then when that timer
fires will use (parts of the) mechanism used by ptrace.
But in the end we need a mechanism to ask for backtraces for existing,
sleeping, threads.
But perf already has that information -- stacktraces on a sched_switch.
We already know where the task is when it is sleeping.
Ok, we need two mechanisms to get that, one for existing, sleeping
threads at the time we start monitoring (we don't have that now other
than freezing the process, looking for threads that were waiting, then
using ptrace and asking for that backtrace), and another for threads
that will sleep/wait_after_ we start monitoring.
That's a missing piece -- callchains for sleeping threads when perf starts.
>I'm interested in the the other side of the fence. The backtrace could/should
>stop at system_call_fastpath.
We talked about this last year - options to control stack depth obtained
on a record. Most flexibility is to allow controls of user space stack
and kernel. Here someone could set kstack depth to 0 to get only
userspace stack.
Right, adding callchains to 'perf trace' and using it with --duration
may provide a first approximation for threads that will start waiting
after 'perf trace' starts, I guess.
Talked about this one too. Integration of perf-script with perf-trace.
So many features, so little time.
David
--
To unsubscribe from this list: send the line "unsubscribe linux-perf-users" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
