Messages in this thread | | | From | Namhyung Kim <> | Date | Tue, 21 Jul 2020 22:44:44 +0900 | Subject | Re: [PATCH v5 03/17] perf ftrace: add option -t/--tid to filter by thread id |
| |
Hi Steve,
On Sat, Jul 18, 2020 at 4:44 AM Steven Rostedt <rostedt@goodmis.org> wrote: > > On Fri, 17 Jul 2020 16:34:55 -0300 > Arnaldo Carvalho de Melo <acme@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).
Yep, perf does look up the /proc to get a list of threads in a process.
Thanks Namhyung
> > 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
| |