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

[Richard Mortier <Richard.Mortier@xxxxxxxxxxxxxxxx>]

On 30 Oct 2014, at 15:40, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:

> On 30 Oct 2014, at 14:30, Len Maxwell <len@xxxxxxxx> wrote:
>> 
>> ...Recently I found the Google trace-viewer [1] tool; it was built to
>> analyze performance issues in Chrome [2], is now being used for
>> Android, and the Go language may adopt it as well [3].  I think it
>> would be worthwhile to a) review their event types and JSON format [4]
>> for inspiration, and b) consider trace-viewer as an alternative viewer
>> for some use cases.
>> 
>> As an experiment, I manually instrumented mirage-www with trace-viewer
>> JSON output, and the result is here [5].  Download that file, open
>> about://tracing in Chrome, then Load the .trace file.  (Failing that,
>> you can get the trace-viewer source [1] and run the dev_server, or
>> view the self-contained HTML/JS version [6]).  Press '?' for help
...
> 
> I didn't even know of the existence of this tool, so the trace format
> looks useful even if the Chrome tool itself doesn't quite match.  The
> HN thread mentioned the LTTng, which doesn't look quite as well used
> as this (which is used for actual profiling in Android and Chrome, by
> the looks of it).

distinguishing the particulars of that viewer from the tracing infrastructure, 
it's worth thinking up front about how far down the tracing infrastructure will 
go.

for magpie we used event tracing for windows[etw][] which is a reasonably 
compact extensible binary format, and so can be used to instrument every 
context switch. probably wouldn't want to be inserting json blobs into a buffer 
at the same rate.

[etw]: 
http://msdn.microsoft.com/en-us/library/windows/desktop/bb968803(v=vs.85).aspx

seems there might be a couple of options here:

+ uniform instrumentation throughout mirage -- probably requires compact 
representation, maybe permits per-unikernel rather than per-subsystem buffers, 
probably simplifies parsing.

+ heterogeneous instrumentation -- may need compact representation(s) for low 
layer things like tracking lwt threads but more trivially extensible things 
like json for higher layer app things. probably more complex to parse and 
integrate across though. different formats presumably need different buffers to 
be written into though and probably end up needing some care as to how events 
at different layers are to be linked up.

-- 
Cheers,

R.

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

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