
<html><body><div style="font-family: times new roman, new york, times, serif; font-size: 12pt; color: #000000"><div>Patch merged with a few coding style fixes.<br></div><div><br></div><div>Thanks!<br></div><div><br></div><div>Mathieu<br></div><div><br></div><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;" data-mce-style="border-left: 2px solid #1010FF; margin-left: 5px; padding-left: 5px; color: #000; font-weight: normal; font-style: normal; text-decoration: none; font-family: Helvetica,Arial,sans-serif; font-size: 12pt;">Hello everyone,<br> <br> 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.<br> 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 :<br><ol><li>The root container (or the host)<br></li><li>The parent container</li><li>The container the task is running into<br></li></ol>We also rebased on master, and everything is running smooth and fine on our test machine (linux 3.19.3). <br> It should support down to linux 3.8.1.<br> <br> Here is an example of a field<big> </big><big>: </big><br> <br> <span style="font-family: Courier New,Courier,monospace;" data-mce-style="font-family: Courier New,Courier,monospace;" face="Courier New, Courier, monospace">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 }</span><br> <br> Any comments are greatly appreciated!<br> <br> Sebastien & Francis.<br> <br> <br><div class="moz-cite-prefix">On 03/31/15 11:50, Sébastien Lorrain wrote:<br></div><blockquote cite="mid:551AC231.102@gmail.com">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" target="_blank" data-mce-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> <span style="text-decoration: underline;" data-mce-style="text-decoration: underline;"><i><br> The modifications to the lttng-modulues where the following:</i></span><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></blockquote><br></blockquote><div><br><br></div><div><br></div><div>-- <br></div><div><span name="x"></span>Mathieu Desnoyers<br>EfficiOS Inc.<br>http://www.efficios.com<span name="x"></span><br></div></div></body></html>