Re: [Xen-devel] [PATCH V4] xen/arm: domain_build: allocate lowmem for dom0 as much as possible

[Stefano Stabellini <sstabellini@xxxxxxxxxx>]

On Wed, 16 Nov 2016, Andrii Anisov wrote:
> > For example, take a look at PVCalls which is entirely based on data
> > copies:
> >
> > http://marc.info/?l=xen-devel&m=147639616310487
> >
> >
> > I have already shown that it performs better than netfront/netback on
> > x86 in this blog post:
> >
> > https://blog.xenproject.org/2016/08/30/pv-calls-a-new-paravirtualized-protocol-for-posix-syscalls/
> >
> >
> > I have just run the numbers on ARM64 (APM m400) and it is still much
> > faster than netfront/netback. This is what I get by running iperf -c in
> > a VM and iperf -s in Dom0:
> >
> >         PVCalls             Netfront/Netback
> > -P 1    9.9 gbit/s          4.53 gbit/s
> > -P 2    17.4 gbit/s         5.57 gbit/s
> > -P 4    24.36 gbit/s        5.34 gbit/s
> >
> > PVCalls is still significantly faster than Netfront/Netback.
> This seems to be not a really fair comparison. And does not reflect
> performance impact of the data copying itself.

Why it is not a fair comparison? Because the design is different or
because of the settings? I am happy to adjust benchmarking settings to
make the comparison fairer.


> Among all, our team is working on PV DRM implementation now. I guess
> the first implementation would have a data copying, then we will
> introduce a zero-copy. So it should be a good example to collect and
> share impact numbers.

Looking forward to them.


> In embedded applications area, we are currently focused on, acceptable
> performance drop, f.e. for io operations, is estimated as 3-5%
> comparing to bare-metal system.

That's very interesting info and certainly a difficult mark to reach.


> Anyway thank you for your comments, suggestions and examples.
> I've got the point that we have to have solid reasoning baked with
> pack of numbers to get something specific to us accepted by community.

Cheers,

Stefano

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel