[MirageOS-devel] Mirage tracing status

[Thomas Leonard <talex5@xxxxxxxxx>]

I've been making some updates to the mirage tracing support, which is now here:

  https://github.com/mirage/mirage-profile

The biggest change is that events are now logged in a binary format to
a bigarray. This has several useful effects:

- Tracing shouldn't put much extra load on the garbage collector.

- The buffer is shared with dom0 at startup and can be read without
requiring cooperation from the unikernel (on Unix, it uses an mmapped
file for a similar effect). This means that traces don't get cluttered
with calls about transmitting the trace data, and that you can extract
trace data from a unikernel that has crashed or is stuck in a loop.

- There is a CTF metadata description of the format, which allows
traces to be processed with other tools. e.g. you can dump a trace to
text using babeltrace.

The format is currently rather inefficient, using 64-bit ints all over
the place (timestamps, thread IDs, counter increments, etc), but we
can improve it over time.

There is no synchronisation between domU and dom0, which means that
the viewer might grab an inconsistent snapshot of the buffer, but it
hasn't happened yet! The usual ring synchronisation might not be quite
right here because it's often better to drop missed trace events if
the viewer is slow or not being used. But we should probably send an
event for each new packet (bundle of events) in case the user wants to
log them to long-term storage. I should check what LTT does here.

The build is now using OASIS and is conditional, so that it compiles
null-ops when lwt.tracing isn't being used. This means you can add
tracing calls to your libraries without any overhead in the
non-tracing case.


The next steps are:

1. Merge mirage-profile into the mirage-dev repo
(https://github.com/mirage/mirage-dev/pull/48) so that other things
can depend on it.

2. Add support to the "mirage" tool. Initially, I added support using
functors in the same way as for other types, but in the common case
where tracing starts automatically at boot and is never stopped
there's no reason for the unikernel to interact with the control
interface at all. So maybe we just need an option ("mirage configure
--enable-tracing"?) or something in the config.ml ("register
~tracing:true ..."?).

3. Add trace annotations to mirage-platform and other libraries.


If anyone has had any success using the tracing themselves (or got
stuck), let me know!


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