[ltt-dev] UST use case: Tracing QEMU/KVM

Stefan Hajnoczi stefanha at gmail.com
Thu May 27 01:21:27 EDT 2010


On Wed, May 26, 2010 at 11:46 PM, Pierre-Marc Fournier
<pierre-marc.fournier at polymtl.ca> wrote:
>> For large programs or programs that closely manage resources, a
>> documented list of resources that libust uses would be useful.  This
>> information can be used to understand whether libust might interfere
>> with the program being traced.  For example, will heap allocations be
>> made after startup?  Will file descriptors be held open?  The listener
>> thread?
>
> Currently, ust is designed to be transparent to the running process in most
> cases. However, if your program makes very unusual assumptions about the
> usage of some resources, this could result in a conflict.
>
> - Yes, heap allocations can be made after startup.
> - Sockets will definitely be kept open by the listener thread.
> - Currently, I don't think any file descriptors are kept open, but it could
> be the case in the future.
> - SystemV shared memory segments are mapped in the address space.
> - A listener thread is always started to wait for connections from ustctl or
> ustd.
>
> If you feel it would be important to avoid some of these things, please let
> me know.

Thanks for explaining, sounds fine to me.  If you want to add this as
an appendix to the documentation I think it is useful information for
an application developer who wants to integrate UST support.

>> I don't understand the --create-trace, --alloc-trace, --destroy-trace,
>> and subbuf concepts that ustctl exposes.  Perhaps these are documented
>> in kernel LTTng and I haven't read that.
>
> Normally you should not need to go to LTTng kernel tracer documentation to
> understand.
>
> I just pushed an updated manpage for ustctl in the git which clarifies these
> concepts. If you think things could be even clearer, let me know.

Great thanks, will check out the documentation.

Stefan




More information about the lttng-dev mailing list