Project

General

Profile

Bug #1157

Re-enable LTTng lock_* tracepoints

Added by Aleix Roca Nonell over 1 year ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
04/10/2018
Due date:
% Done:

0%

Estimated time:

Description

Currently, the Linux kernel features a set of lock tracepoints which track lock acquisition and contention [1]:

  • lock_acquire
  • lock_acquired
  • lock_contended
  • lock_release

However, the current version of LTTng (2.10, current master be02509026) does not instrument this tracepoints (the code is in the source code but commented [2]). The guys on LTTng IRC helped me enabling them again by just uncommenting the code in lttng-modules/probes/Kbuild .

Thanks to these tracepoints, I could create a couple of Trace Compass views to easily track the kernel lock contention, which clearly showed me what was going on. Please, see the attached screenshot for an example. The application under analysis is a parallel cholesky benchmark run on a server with 56 CPUs. I was trying to figure out why almost all application threads became blocked at some point as seen in the screenshot. The lock view showed that there was a huge contention on the mm->mmap_sem lock when all threads tried to allocate memory by calling mmap(), mmprotect() and triggered page faults when data is written on the recently mmapped memory.

Hence, what I would like to point out is how useful it has been for me to enable the LTTng lock tracepoints. I think it would be great if they could be added back again into mainland.

[1] See Documentation/locking/lockstat.txt on the Linux Kernel source for more information.
[2] As Compudj pointed out, the reason is found in this conversation: https://lists.lttng.org/pipermail/lttng-dev/2012-December/019256.html


Files

cholesky-lock-analysis.png (147 KB) cholesky-lock-analysis.png Aleix Roca Nonell, 04/10/2018 11:38 AM

Also available in: Atom PDF