On Fri, 17 Jul 2020 16:34:55 -0300 Arnaldo Carvalho de Melo <a...@kernel.org> wrote:
Thinking a bit more, I have to ask. Does perf use the kernel when getting all the children of an existing task, or is that done only in userspace? That is, is there a perf syscall that says "start tracing this task and all its existing children"? Or is it done by perf user space looking at the /proc filesystem (like ps does). I'm asking because if perf has a syscall to do that, then I probably should add a way to do that with ftrace as well. But that's really trivial, because all it would take is grabbing the task_list lock and iterating over all the children. Getting new children was the non-trivial part, which was what I focused on (with the fork options). If perf does it with proc files, then we don't need to change anything as that could still be used with ftrace. > Changbin, you can take from here :-) > > And to reiterate, for me the value of 'perf ftrace' is to allow people > used to perf to be able to switch to ftrace quickly, just changing: > > perf record/top/stat/trace/report/script/etc --pid 1234 > > by: > > perf ftrace --pid 1234 > > And have the tracefs ftrace knobs set up to have what is expected in > terms of targets to trace as the other perf tools. > > And not just --pid and --tid, but --cgroup, --cpu, etc. > > i.e., 'perf ftrace' being _a_ front-end aplication to ftrace. > > :-) I have no problem with this, and I'm quite excited about it. I would like it to use libtracefs, as it looks to be exactly what we are working on. And this is now a high priority to get out, and I don't expect another year (or two) in doing so ;-) -- Steve
