Re: [MirageOS-devel] Mirage tracing

[Thomas Leonard <talex5@xxxxxxxxx>]

On 9 October 2014 11:25, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:
>>> I'm currently working on improving the profiling support in Mirage.
>>> Previously [1], I was just graphing stats in libreoffice and looking
>>> at call traces, but I've been thinking about how to get more useful
>>> data.
>>>
>>> Tracing individual functions was too fine-grained, I think, and failed
>>> to follow Lwt threads, so I intrumented Lwt to record when threads are
>>> created and resolved, and the interactions between them. Graphing the
>>> results looks like this:
>>>
>>>  http://test.roscidus.com/static/block-read-mirage-x86.png
>>>
>>>  ( trace file: http://test.roscidus.com/static/log-x86.sexp )
>
> That's pretty cool! That would be even cooler to have a HTML/CSS/javascript 
> output on a "debug" port for any unikernel :-)

It's using cairo for rendering, so producing png or svg output should
be easy. My javascript skills aren't up to making it zoom smoothly in
a browser though...

>> How should tracing work with existing mirage libraries? We want
>> libraries to be able to report extra information (thread labels, when
>> significant events occur, performance counters, etc), but we also want
>> high performance when tracing is off.
>>
>> One possibility is a mirage-tracing library whose default
>> implementation does nothing. I imagine the OCaml compiler would
>> optimise all calls to the library away, using cross-module inlining.
>> Then you could opam pin the real version if you wanted tracing on.
>>
>> Or is it better to make it dynamic, so tracing can be enabled at any
>> time without recompiling? Or with a functor applied by the mirage
>> tool? Any suggestions?
>
> I think we were discussing having a special "Tracer" (or "Profiler") module 
> type, similar to the "Console" one. Or to extend the "Console" one with more 
> structured kinds of debug statement. Not sure what is the most practical, but 
> we should certainly do something to support what you have started to do at a 
> larger scale.

Cool, I'll make a static tracing module for now then.

> And yes, having a dummy Profiler where no-op are optimised away is a good 
> idea. Hopefully, Pierre Chambart's patches for improving the inliner will be 
> in OCaml before Mirage 3.0 :-)


-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

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