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

[Pierre-Marc Fournier]

Stefan Hajnoczi wrote:
> On Mon, May 24, 2010 at 4:57 AM, Pierre-Marc Fournier
> <pierre-marc.fournier at polymtl.ca> wrote:
> 
> Thanks for the quick reply, Pierre-Marc.
> 
>> If there are specific subjects in mind you feel would benefit from being covered in more depth in the manual, please let me know.
> 
> 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.

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

> 
>>> One note about the manual: the TP_PROTO() versus TPPROTO() change was
>>> confusing.  Perhaps a note can be added to the manual that ust.git
>>> uses TP_PROTO() but libust 0.4 uses TPPROTO()?
>> This reflects an API change in the kernel. But you are right, this is confusing. I will do a 0.5 release next week, which will obsolete 0.4 and sync the manual.
> 
> Thanks.
> 
>>> poll([{fd=3, events=POLLIN}], 1, -1)      = ? ERESTART_RESTARTBLOCK (To
>>> be restarted)
>>> restart_syscall(<... resuming interrupted call ...>) = ?
>>> ERESTART_RESTARTBLOCK (To be restarted)
>> Hmmm. Do you have any pointers to documentation about this return code? I suspect userspace should never see it. Could it be a kernel bug?
> 
> I have sent an example that triggers this behavior and explains how it
> can occur.
> 

Will look at this shortly.