[lttng-dev] Added information about PID namespace to tracepoints

[Sébastien Lorrain]

Hello fellow LTTNG devs,

We are students from Polytechnique Montreal and we are currently working 
on an TraceCompass analysis module for Linux containers 
(LXC/Docker/Etc...). The information we track is mostly CPU usage by pid 
namespace, which would allow the identification of CPU-utilization 
related bottlenecks on a Linux container host.

We tried to come up with targeted information to recreate the 
container/PID namespace tree of a Linux host and we have modified 
lttng-modules to be able to do so :
https://github.com/Selora/lttng-modules

In our analysis, we try to re-use as many information that was already 
available in the LTTNG kernel tracer. We build our container/namespace 
tree using the tasks and their parent recursively (using only the 
pid/vppid/ppid). However, we were unable to have a reliable model 
without some light modifications on some tracepoints.
_/
The modifications to the lttng-modulues where the following:/_

We added the PID namespace INode (from /proc/PID/ns/pid) to the LTTNG 
statedump tracepoint.

Also, to track new task/containers that would spawn during the tracing 
session, we also added multiple fields to the /sched_process_fork/ event :

  * Added a VTID field for the children task. This is mandatory in our
    analysis, as we keep track of VTID/TID association.
  * Added a/parent_ns_inum/ and /child_ns_inum/ field wich represent the
    pid namespaces inodes of the parent and child task respectively.
      o The /parent_ns_inum/ is "not mandatory" in our analysis, but it
        keeps things simple as we don't have to track TID from parent
        containers and it keeps the code relatively independant wheter
        statedump is enabled or not.
      o The /child_ns_inum///IS mandatory, because even if we keep track
        of the PID/VPID/PPID/VPPID that have spawned, it is possible to
        "inject" a task in an already existing namespace without
        repareting it to the child reaper of the container (this means
        the task is sent in a namespace, but it is not part of the
        process tree of the container of that namespace)

We hope to integrate our analysis to TraceCompass soon, and without the 
modification to the LTTNG tracer approved, we would be unable to proceed 
throught code review.
We would be really grateful to the community if we could have feedback, 
and we will make every modifications possibles to have our analysis up 
and working!

The code is supposed to work on kernel version 3.8 through 3.19.
It was tested on 3.18 and 3.19, and I'am going to test it for 3.8 today.

Cheers,
Sebastien & Francis.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20150331/41061a85/attachment-0001.html>