[lttng-dev] Kernel Lock Analysis

[Jonathan Rajotte-Julien]

Hi,

On Thu, Apr 05, 2018 at 11:17:57AM +0200, aleix wrote:
> Hello List! This is my first message here :)

Welcome!

> 
> I would like to share my experience playing with Kernel lock
> instrumentation, LTTng and Trace Compass which might be useful for
> others when analyzing applications behavior.
Before going further, you might want to repost this on the Tracecompass mailing
list:

https://accounts.eclipse.org/mailing-list/tracecompass-dev

They are most likely interested by all of this.

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

Given your current use case, it make a compelling point toward spending some
time investigating the possibility of making those tracepoints accessible.

Would you mind creating a bug here [1] regarding this so we can track it in the
future?

[1] https://bugs.lttng.org/projects/lttng-modules/

> If this can be done, I
> think it woulde make sense to propose the Trace Compass people to
> include a kernel lock view.
> 
> It looks like the lock events are by far the most frequent events,
> quickly filling LTTng buffers. However, they are only generated if the
> kernel is compiled with CONFIG_LOCK_STAT so this should not annoy the
> unaware user.
> 
> I hope my experience is of help! Thanks a lot for your work! :D

Absolutely, we are always interested in how our tools are used in the wild.

Thanks for sharing.

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

-- 
Jonathan Rajotte-Julien
EfficiOS