Re: Utility of PV on non-obsolete hardware

["Mathew, Cherry G." <cherry%zyx.in@localhost>]

On 4 April 2019 4:53:31 PM GMT+05:30, tg%gmplib.org@localhost wrote:
>"Mathew, Cherry G." <cherry%zyx.in@localhost> writes:
>
> That's a good point - I'm surprised about the I/o performance though -
>  were you using virtio ?
>
>I was not.
>
>I lamely tried to enable virtio for networking, but got an error
>message.  I didn't try virtio for disk ops.
>
>The compile test I performed reads each source over NFS and writes
>objects to a local disk.  The local disk is provided via a Gentoo Dom0
>through LVM.  So there is a fair bit of networking and disk ops going
>on, but still not very much compared to the CPU used by the compiler.
>
>The speed difference is huge between different OSes.  Here is a table
>for the main builds on the Goldmont system:
>
>   glmfbsd64v10.gmplib.org-stat:64.txt   214
>   glmfbsd64v93.gmplib.org-stat:64.txt   234
>   glmfbsd64v11.gmplib.org-stat:64.txt   305
>   glmfbsd64v12.gmplib.org-stat:64.txt   308
>   glmnbsd64v80.gmplib.org-stat:64.txt   329
>    glmdeb64v10.gmplib.org-stat:64.txt   335
>     glmdeb64v8.gmplib.org-stat:64.txt   341
>     glmdeb64v7.gmplib.org-stat:64.txt   347
>     glmdeb64v9.gmplib.org-stat:64.txt   366
>    glmgentoo64.gmplib.org-stat:64.txt   395
>   glmnbsd64v61.gmplib.org-stat:64.txt   498
>   glmnbsd64v70.gmplib.org-stat:64.txt   502
>   glmnbsd64v71.gmplib.org-stat:64.txt   508
>   glmnbsd64v72.gmplib.org-stat:64.txt   509
>            glm.gmplib.org-stat:64.txt   541
>
>(The system naming might seem awkward, but I think it's pretty clear
>what the abbreviations mean.)
>

Thanks for this, it's a useful reference.

>Usual caveat: While all systems build exactly the same sources, the
>systems run different compilers as well as /bin/sh.
>
>The slowest systems all use PV.  The system glm.gmplib.org is the Dom0,
>which is not (yet) under PVH.  Then comes all PV NetBSD systems.
>
>Some of the apparent speedup with HVM is also a slowdown in the Dom0,
>as
>its qemu processes use up a fair amount of CPU.
>

This makes more sense - HVM will outperform PV in CPU bound processes, whereas without PVHVM HVM alone would be a bottleneck via the dom0 qemu process for i/o bound precesses, while PV enjoys xen driver optimisation.


>   I'm about 70% of the way enabling PVHVM for domU - we have PoC but
> needs a bit more debugging etc. Also looking at non PV Dom0 solutions.
>
>That's good news!  That should help to lower the Dom0 load.
>
>Are there also plans for PVH?

Yes, that is the plan - or at least to look at all options for a non-PV dom0.

Cherry

-- 
Sent from my phone. Please excuse my brevity.