Xen project Mailing List

On Sun, Feb 15, 2015 at 11:28 AM, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:

On 15 Feb 2015, at 11:19, Richard Mortier <richard.mortier@xxxxxxxxxxxx> wrote:
>
> On 15 February 2015 at 11:15, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>> This is great to see -- thanks for working on this Masoud!
>>
>> In particular, having even a simple iperf test would let us test
>> several interesting combinations straight away:
>>
>> - vary OCaml version (4.01 vs 4.02 is now supported), and there
>>Â is an experimental inlining branch in 4.03dev that could directly
>>Â be tested using this infrastructure.
>
> ok-- so i guess that needs a switch/env var to specify the `opam switch` to use?

Yeah.Â Although from the performance scripts' perspective, it's better
if they just assume that there is a working OPAM environment.Â It would
be easier to control these parameters from outside, and keep the perf
scripts as easy to run as possible.

A couple of other things that might help:

- Luke Dunstan has a rather comprehensive acceptance test suite for
Â MDNS: https://github.com/infidel/ocaml-mdns/tree/master/lib_test/acceptance

- OCamlPro has a benchmarking system for core OCaml here that may have
Â some useful libraries: https://github.com/OCamlPro/operf-macro

- Performance tests could be wrapped using Core_bench, which
Â does linear regression across runs.
Â https://realworldocaml.org/v1/en/html/understanding-the-garbage-collector.html#the-mutable-write-barrier

>
>> - evaluate the impact of some features incoming such as the open
>>Â RFC for checksum offload.
>
> how are they specified -- as a PR?
> in which case, masoud-- i guess that
> https://help.github.com/articles/checking-out-pull-requests-locally/
> is a starting point for how to specify a particular PR rather than
> simply a commit rev.

Yes, although again this would be better done outside the performance
harness as an OPAM pin for the local environment.Â Just having the
ability to quickly run a performance test would be invaluable at this
stage.

>
>> In terms of immediate feedback, I'd request a version that just does
>> iperf so that it has no dependencies on the host dom0 kernel.
>> See: https://github.com/mirage/mirage-skeleton/pull/75
>
> just to be clear -- you mean does iperf via unikernels, ie., all the
> tests that are executed should also be unikernels rather than standard
> tools so that we don't take dependencies on an underlying platform
> like the dom0?

Yes -- Xen unikernels would be the primary target.

Starting and stopping VMs in open source Xen can be bit of a pain, so
it would be ok if the test harness used XenServer (which the ARM SDcard
images now include).Â Jon or Dave could comment on the state of the XMLRPC
OCaml bindings to XenServer...

The cubieboard images are working ok for me-- I've got 2 of them and am using XMLRPC to manage them remotely.

The OCaml XenAPI bindings are in the opam "xen-api-client" package and in this repo:

https://github.com/xapi-project/xen-api-client

There are simple examples in there including

$ ./list_vms.native -uri http://cubieboard2.local. -u mirage -pw mirage 2> /dev/null

VM Control domain on host: cubieboard2

VM www

The client bindings are slightly tweaked versions of the ones used in xenserver, which are battle-tested. There are lots of things about their style which I don't like and would like to improve, but they do work. Feel free to create issues in the issue tracker if you find bugs, or have improvement suggestions. I'd like to fix lots of issues and make a single new major release, and then take the time to port the xapi/xenserver codebase over.

For talking to test VMs I recommend writing the IP address to xenstore which will then be available via the XenAPI. You can then connect to the unikernel via TCP/IP. Eventually we might be able to switch to vchan but I think TCP over netfront is more reliable.

Jon: where is your Mirage "guest agent" that can do shutdown (and could be extended to report info like IP address)?

Dave

>
>> For this repository, what is the supported dom0 kernel that is expected?
>> The script tried to insmod a kmod that I didn't have.
>
> over to masoud...
>
>> Once there's even a minimal test, I'd like to recreate it on an
>> infrastructure machine in Cambridge and have it run daily via cron
>> alongside the is-mirage-broken scripts.
>
> cool... (one day i must learn about the cambridge infrastructure machines :)

Be careful what you wish for :)

Anil

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

Dave Scott

Re: [MirageOS-devel] performance regression tests