Re: [MirageOS-devel] Mirage tracing

[Len Maxwell <len@xxxxxxxx>]

Hello,

This looks like a good start.  I've created similar specialized tools for
post-processing and visualization in the past, and they are usually
worth the investment.

On Tue, Oct 7, 2014 at 11:09 AM, Thomas Leonard <talex5@xxxxxxxxx> wrote:
> By default, threads just appear as numbers, but I added some code to
> my unikernel to label some them (I didn't annotate any of the Mirage
> libraries, though). For example, the "B.read" thread is what the
> unikernel gets back when it calls B.read on the block device, but you
> can see that behind this mirage-block-xen is creating other threads.

Looking at your example, threads 930 and 945 are ostensibly created
from the same line of code, during separate iterations through the
read loop.

Would it be practical to capture the caller's PC during thread creation,
and dump that out with the Lwt.current_id?  With that you could label
930 and 945 in a way that makes their common caller more obvious,
ex. 930-0x1234 and 945-0x1234 vs 929-0x4567.

(Or better yet, translate PC to source/line info during post-processing?)

In other words, some amount of automated labeling might be a good
complement to manual labeling.


Once you can recognize common patterns in thread creation, you can
present them more clearly in the visualization.  The resulting data might
also be amenable to flame graph visualization:

http://www.brendangregg.com/flamegraphs.html
http://www.brendangregg.com/Slides/LISA13_Flame_Graphs.pdf


Out of curiosity, what happened to thread 934?  Is that a failure, or
an unread result that gets garbage collected?


--
Len

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel