<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=utf-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hello fellow LTTNG devs,<br>
<br>
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.<br>
<br>
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 :<br>
<a href="https://github.com/Selora/lttng-modules">https://github.com/Selora/lttng-modules</a><br>
<br>
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.<br>
<u><i><br>
The modifications to the lttng-modulues where the following:</i></u><br>
<br>
We added the PID namespace INode (from /proc/PID/ns/pid) to the
LTTNG statedump tracepoint.<br>
<br>
Also, to track new task/containers that would spawn during the
tracing session, we also added multiple fields to the <i>sched_process_fork</i>
event :<br>
<ul>
<li>Added a VTID field for the children task. This is mandatory in
our analysis, as we keep track of VTID/TID association.</li>
<li>Added a<i> parent_ns_inum</i> and <i>child_ns_inum</i> field
wich represent the pid namespaces inodes of the parent and child
task respectively.</li>
<ul>
<li>The <i>parent_ns_inum</i> 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.</li>
<li>The <i>child_ns_inum</i><i> </i>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)</li>
</ul>
</ul>
<p>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.<br>
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!<br>
</p>
<p>The code is supposed to work on kernel version 3.8 through 3.19.<br>
It was tested on 3.18 and 3.19, and I'am going to test it for 3.8
today.<br>
</p>
<p>Cheers,<br>
Sebastien & Francis.<br>
</p>
</body>
</html>