Re: [MirageOS-devel] magpie reference

[Thomas Leonard <talex5@xxxxxxxxx>]

On 15 October 2014 23:11, Richard Mortier
<Richard.Mortier@xxxxxxxxxxxxxxxx> wrote:
>
> On 15 Oct 2014, at 12:08, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>
>> On 14 October 2014 16:48, Richard Mortier
>> <Richard.Mortier@xxxxxxxxxxxxxxxx> wrote:
>>> from call:
>>>
>>> http://www.cs.nott.ac.uk/~rmm/papers/pdf/osdi04-magpie.pdf
>>>
>>> http://dl.acm.org/citation.cfm?id=1251272
>>
>> Thanks for the reference. Being able to highlight all threads related
>> to a particular input event could be useful, indeed.
>
> yes; both to see system structure and also to understand performance in 
> detail. eg., could your Lwt monitoring changes also sample cycle counter (or 
> whatever would be appropriate in a domU?) so as to annotate segments with 
> resources consumed?

Could do. If you pin the domU to its own CPU then the clock times
should be a good estimate anyway, though.

>> In the current
>> system, we can see that e.g. the blkfront.poll thread gets woken up
>> for each read response and notifies the main thread waiting for the
>> data:
>>
>> http://test.roscidus.com/static/html_viewer.html?t_min=8249.586333&t_max=8249.588562
>>
>> But we don't link it back to the original request. In this case just
>> marking the request on the diagram would make it obvious what's
>> happening, but in more complicated cases some visual indication of the
>> original source could be useful.
>
> note that one of the key issues we had when parsing events was the 
> brittleness of the parser to events being reordered or dropped -- making it 
> remarkably easy to end up in a state where nearly all events were either 
> assigned to the same request or to no request.
>
>> You could probably do your clustering analysis on these traces if you
>> wanted to. Instrumenting Lwt gets you a lot of information
>> automatically that you would otherwise have to write schemas for, but
>> you do still need to handle the multiplexing problem.
>
> not sure what you mean by the multiplexing problem?

For example, you may have many components being notified by the
blkfront polling thread when their disk operations complete, but they
shouldn't all be linked together. So (as your paper notes) you need to
add some extra code in places to handle this.

>  if simply the need to trace the impact of input requests, the two solutions 
> that were followed at the time were to assign each request a unique id, or to 
> maintain mapping tables at every "module" boundary so things could be 
> stitched together. we strongly believed (and i still strongly believe) that 
> the latter is preferable-- it makes the tracing infrastructure much more 
> general and usable, with little extra overhead and obviates the need to 
> generate unique ids for inputs (which becomes fiddly in a distributed system).

Makes sense.


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