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

[Mathieu Desnoyers]

Patch merged with a few coding style fixes. 

Thanks! 

Mathieu 

----- Original Message -----

> Hello everyone,

> We changed the patch code a bit to include all of the VTIDs of a task nested
> deep down in an arbitrary level of pid namespace.
> For example, if a task is running inside a container nested in another
> container, our patch will display the TID of the task from the point of view
> of :

> 1. The root container (or the host)
> 2. The parent container
> 3. The container the task is running into

> We also rebased on master, and everything is running smooth and fine on our
> test machine (linux 3.19.3).
> It should support down to linux 3.8.1.

> Here is an example of a field :

> sched_process_fork: { cpu_id = 0 }, { parent_comm = "bash", parent_tid =
> 10739, parent_pid = 10739, parent_ns_inum = 4026532365, child_comm = "bash",
> child_tid = 10968, _vtids_length = 3, vtids = [ [0] = 10968, [1] = 2658, [2]
> = 1265 ], child_pid = 10968, child_ns_inum = 4026532365 }

> Any comments are greatly appreciated!

> Sebastien & Francis.

> On 03/31/15 11:50, Sébastien Lorrain wrote:

> > 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.
> 

> > * 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.
> 
> > * 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.
> 

-- 
Mathieu Desnoyers 
EfficiOS Inc. 
http://www.efficios.com 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lttng.org/pipermail/lttng-dev/attachments/20150506/87cece1b/attachment-0001.html>