Re: [PATCH -v2] ftrace: Documentation

[ebiederm@xmission.com (Eric W. Biederman)]

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