On 9/18/14, 1:17 PM, Arnaldo Carvalho de Melo wrote:
This was also why I asked my initial question, which I want to repeat once
>more: Is there a technical reason to not offer a "timer" software event to
>perf? I'm a complete layman when it comes to Kernel internals, but from a user
>point of view this would be awesome:
>perf record --call-graph dwarf -e sw-timer -F 100 someapplication
>This command would then create a timer in the kernel with a 100Hz frequency.
>Whenever it fires, the callgraphs of all threads in $someapplication are
>sampled and written to perf.data. Is this technically not feasible? Or is it
>simply not implemented?
>I'm experimenting with a libunwind based profiler, and with some ugly signal
>hackery I can now grab backtraces by sending my application SIGUSR1. Based on
Humm, can't you do the same thing with perf? I.e. you send SIGUSR1 to
your app with the frequency you want, and then hook a 'perf probe' into
your signal... /me tries some stuff, will get back with results...
Current profiling options with perf require the process to be running.
What Milian want is to grab samples every timer expiration even if
process is not running.
Any limitations that would prevent doing this with a sw event? e.g,
mimic task-clock just don't disable the timer when the task is scheduled
out.
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
