Re: [MirageOS-devel] Tracing and profiling blog post

[Thomas Leonard <talex5@xxxxxxxxx>]

On 27 October 2014 11:07, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>
>> On 27 Oct 2014, at 11:02, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>>
>> On 27 October 2014 10:47, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>>> On 27 Oct 2014, at 10:42, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>>>>
>>>> I've put up a blog post describing the tracing work:
>>>>
>>>> http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/
>>>>
>>>> It explains how to read the diagrams, what the various arrows mean and
>>>> how to instrument your own programs. There are examples from tracing
>>>> some Mirage unikernels. The viewer should now also work on tablets
>>>> (pinch to zoom) - though probably very slowly! Let me know if there
>>>> are any browser compatibility problems...
>>>
>>> Great post as always!  My first reaction was wincing at the inefficiency
>>> of scatter-gather IO.  Perhaps we should indeed expose a copying API to
>>> minimise the guest VM <-> backend ring traffic...
>>
>> Wow - impressive speed-reading skills there!
>
> Admittedly, I started reading when you posted on Twitter :-)
>
>>
>>> What are the next steps to get the profiling modules into mirage-dev
>>> so that we can start sprinkling this in all of our libraries?
>>
>> I need to make mirage-profile detect whether lwt.tracing is installed
>> and compile null-op functions if it isn't. The API needs a little
>> cleaning up too (e.g. note_increase should probably take a counter
>> object rather than a string), but that shouldn't be much work -
>> libraries don't need to use many calls to provide useful trace
>> information.
>>
>> The API for controlling tracing and the trace format may continue to
>> change, but that shouldn't break libraries that are just providing
>> trace data.
>>
>
> Makes sense -- the longest path is likely to be the patches to
> upstream Lwt to get lwt.tracing in.  It's a core enough dependency
> that requiring people to pin it all the time is probably impractical
> outside of mirage-dev.

Note that everything should (in future) compile with an unmodified
Lwt. Pinning the tracing version of Lwt is what will trigger
everything to recompile with profiling support. So, getting this
upstream shouldn't block anything (and might indeed be difficult),
although if upstream wants to add a flag for it that would be great
too.

This is a change to my previous plan of having Lwt depend on
mirage-profiling. Now, mirage-profiling depends on Lwt. If you want to
use any extended feature of Lwt you should go via profiling. e.g. in
mirage-platform we have:

let ports = Array.init nr_events (fun port -> {
  counter = program_start;
  c = Profile.named_condition ("after-chn-" ^ string_of_int port)
})

If Lwt.tracing is installed then Profile.named_condition is:

let named_condition label =
  Lwt_condition.create ~label ()

Without, it will be:

let named_condition _label = Lwt_condition.create ()


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