Re: [MirageOS-devel] Parallelizing writing to network devices

[Thomas Leonard <talex5@xxxxxxxxx>]

On 28 November 2014 at 16:24, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>
>> On 28 Nov 2014, at 16:03, Masoud Koleini <masoud.koleini@xxxxxxxxxxxxxxxx> 
>> wrote:
>>
>> Thanks Anil.
>>
>>> - graph the ring utilisation to see if it's always full (Thomas Leonard's 
>>> profiling patches should help here)
>>
>> Would you please point me out to the profiling patches?
>
> See: 
> http://roscidus.com/blog/blog/2014/10/27/visualising-an-asynchronous-monad/

The installation instructions here are for the previous version
(though they should still work). If you want to try the latest
version, the current Git mirage allows you to pass a ~tracing argument
to "register" in your config.ml, e.g.

let tracing = mprof_trace ~size:1000000 () in
register "myunikernel" ~tracing [
  main $ ...
]

This uses a newer version of the profiling API. You should generally
"opam pin" the #tracing2 branches rather than #tracing to use it.

Note also that it doesn't currently record ring utilisation, so you'll
still need to do some work to get that. You could use the
MProf.Counter interface, in which case the GUI will display it as a
graph over the trace.

>>> - try to reduce the parallelisation to see if some condition there 
>>> alleviates the issue to track it down.
>>
>> Reducing the maximum number of threads running in parallel reduced CPU 
>> utilization, and vm was functioning for a much longer time, but the same 
>> problem occurred at the end.
>>
>> It might be more useful looking at the code. Please have a look at the 
>> function "f_thread" in the file uploaded on the following repo:
>>
>> https://github.com/koleini/parallelisation
>
> That's a lot of code to try and distill down a test case.  Try to cut it down 
> significantly by building a minimal Ethernet traffic generator that outputs 
> frames with a predictable pattern in the frame, and a receiver that will 
> check that the pattern is received as expected.
>
> Then you can try out your parallel algorithm variations on the simple 
> Ethernet sender/receiver and narrow down the problem without all the other 
> concerns.
>
> Once the bug is tracked down, we can add the sender/receiver into 
> mirage-skeleton and use it as a test case to ensure that this functional 
> never regresses in the future.  Line rate Ethernet transmission has worked in 
> the past, but we never added a test case to ensure it stays working.
>
> Anil
> _______________________________________________
> MirageOS-devel mailing list
> MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
> http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel



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