Messages in this thread | | | From | (Eric W. Biederman) | Date | Mon, 14 Jul 2008 19:41:47 -0700 | Subject | Re: [PATCH -v2] ftrace: Documentation |
| |
Steven Rostedt <rostedt@goodmis.org> writes:
>> Ok. So this is something simpler to use then SystemTap. Yeah. > > Yes, very similar. SystemTap may even hook into ftrace, and vice versa.
Got it.
>> It sounds like it is reasonable or at least semi reasonable to use >> this as an unprivileged user. > > Currently only root can do the traces. Since some of the tracing can > hurt the performance of the system.
Reasonable.
>> The easiest model to think of this in is a chroot that does pids as >> well as the filesystem. In which case if you are inside one and >> you use the tracer. You want pids that are meaningful in your >> subset of userspace, and not the global ones. > > Some tracers do a trace at every function call. This uses the gcc -pg > option to set up the start of each function to call profiling code. > Dynamic ftrace is a on the fly code modification to maintain good > performance while tracing is disabled. > > Because of this being such a high critical path, can I get the namespace > pid information directly from the task structure. Any function that is > called must also be careful to not fall back into the tracer. The trace > deals with self recursion, but functions that call back to the tracer > cause a bigger performance impact while tracing.
All of the interesting functions are inline so it shouldn't be a big deal. Mostly they exist to keep the semantics clear as we refactor the code. task_pid_nr(tsk) yields the global pid number, and is currently implemented as just tsk->pid. task_pid(tsk) yields the struct pid.
task_pid_nr_ns(tsk) yields the pid number from the perspective of a specific task.
struct pid is interesting because it is immune from pid roll over conflicts. I don't know if that is any use to you or not.
stuct pid contains an embedded array of the pid_nrs one for each namespace the struct pid is in.
Eric
| |