Em Thu, Sep 18, 2014 at 02:17:49PM -0600, David Ahern escreveu: > 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 Ok, so you want to see what is the wait channel and unwind the stack from there? Is that the case? I.e. again, a sysrq-t equivalent? > Milian want is to grab samples every timer expiration even if process is not > running. What for? And by "grab samples" you want to know where it is waiting for something, together with its callchain? > 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. I'm just trying to figure out if what people want is a complete backtrace of all threads in a process, no matter what they are doing, at some given time, i.e. at "sysrq-t" time, is that the case? - Arnaldo -- 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
