Re: [MirageOS-devel] Mirage tracing

[Thomas Leonard <talex5@xxxxxxxxx>]

On 14 October 2014 13:10, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx> wrote:
> very very interesting, thanks!
>
> We have a lot of small anonymous threads which immediately die after 
> starting: I guess they are related to constant Lwt.return threads ...

Actually, the tracing code in Lwt.return uses the parent's thread ID,
so they don't appear as separate threads (though perhaps they should).

However, each use of >>= does create a new thread.

> Grepping "return ()" has a few hits in mirage-platform/xen.  Using 
> "return_unit" instead should improve these allocations. Not sure how to 
> propagate this constant threads more automatically/widely though.

I haven't seen this cause any problems yet, but using return_unit
might lose useful information when tracing, because if e.g. two
threads return_unit and each has another thread waiting for it, it
will look like they were both waiting for the same thread.


> Thomas
>
>
> On 14 Oct 2014, at 12:14, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>
>> On 9 October 2014 13:54, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>>> On 9 Oct 2014, at 12:25, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>>>
>>>> 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...
>>>
>>> Regarding rendering, Daniel Buenzli's Vz library does have a js_of_ocaml
>>> backend, so this may be a good place to get started on a browser backend
>>> without the trouble of learning HTML/CSS:
>>>
>>>  http://erratique.ch/software/vg
>>
>> I almost had it working with Vg, but there seemed to be no way to
>> measure the text, which is needed to place the labels, so I ended up
>> using HTML canvas directly. As it turned out, that API was a better
>> fit for me anyway (being more similar to Cairo's API).
>>
>> You can test it here:
>>
>> http://test.roscidus.com/static/html_viewer.html?t_min=8249.530963&t_max=8249.534574
>>
>> Scroll to zoom and drag to scroll as usual. Tested on Linux with
>> Firefox and Chromium; let me know if it works elsewhere.
>>
>> It doesn't support touch, so won't work on tablets (also, would
>> probably be very slow).
>>
>>> I'll send an update on Conduit soon, but Dave Scott has added sufficient
>>> Cohttp support that we could expose a Cohttp/Vchan from a unikernel and
>>> access it via Linux userspace.  In other words: you can use Chrome or 
>>> Firefox
>>> to access the debugging port without going through TCP, which is pretty
>>> cool :-)
>>
>>> -anil
>>
>>
>>
>> --
>> 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
>



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