[Libosinfo] [osinfo-db PATCH 1/3] workload: Add high performance

[Daniel P. Berrangé]

On Sat, Nov 17, 2018 at 01:06:11AM +0100, Martin Kletzander wrote:
> This is an example workload that sums up the "common knowledge" that virtio
> devices have the best performance.

Already today when using libosinfo, a mgmt app will know which
devices are "better". ie any application which supports QEMU will
always try to use virtio-net, before trying e1000(e), before
trying rtl8139, etc. So will query libosinfo to find out which
of these devices an OS supports and use the best available.

IOW, if a guest supports virtio-XXX an mgmt app will already be
enabling them by default.

So what value is added by having a workload list these devices,
as opposed to what the app will do today when using libosinfo ?

Or to put it another way, if the user didn't pick the "high-perf"
workload and instead got a different workload that didn't list
any devices, what difference would there be to guest config ?

If anything following the workload recommendation would be a
step backwards because it is KVM specific, not considering
the Xen paravirt devices.


> As a possible addition it also shows the optimal (let's say) number of I/O
> threads to choose.
> 
> Signed-off-by: Martin Kletzander <mkletzan at redhat.com>
> ---
>  data/workload/example.com/high-perf.xml.in | 38 ++++++++++++++++++++++
>  1 file changed, 38 insertions(+)
>  create mode 100644 data/workload/example.com/high-perf.xml.in
> 
> diff --git a/data/workload/example.com/high-perf.xml.in b/data/workload/example.com/high-perf.xml.in
> new file mode 100644
> index 000000000000..9c3aec7d811e
> --- /dev/null
> +++ b/data/workload/example.com/high-perf.xml.in
> @@ -0,0 +1,38 @@
> +<libosinfo version="0.0.1">
> +<!-- Licensed under the GNU General Public License version 2 or later.
> +     See http://www.gnu.org/licenses/ for a copy of the license text -->
> +  <workload id="http://example.com/high-perf">
> +    <short-id>high-perf</short-id>
> +    <_name>High Performance</_name>
> +  </workload>
> +
> +  <devices>
> +    <device id="http://pcisig.com/pci/1af4/1052"/> <!-- virtio1.0-input -->
> +    <device id="http://pcisig.com/pci/1af4/1048"/> <!-- virtio1.0-scsi -->
> +    <device id="http://pcisig.com/pci/1af4/1044"/> <!-- virtio1.0-rng -->
> +    <device id="http://pcisig.com/pci/1af4/1042"/> <!-- virtio1.0-block -->
> +    <device id="http://pcisig.com/pci/1af4/1041"/> <!-- virtio1.0-net -->
> +  </devices>



> +
> +  <features>
> +    <!--
> +        These can be:
> +          - just list of strings
> +          - or list of feature-IDs where feature is a new object that has:
> +             - description
> +             - and human explanation of what to set and how
> +    -->
> +    <iothreads>yes</iothreads>

I wonder if this is too simplistic to really be useful ?

I feel like an mgmt app shouldn't need a workload to say iothreads=yes
in order to know that using iothreads is a good idea for maximising
performance when the guest has > 1 vCPU.  IOW there's only really one
right answer and that's iothreads=yes


> +    <!--
> +        probably pointless, but someone might want to be able to specify
> +        something like:
> +         <iothreads>
> +           <min>
> +             <cpus/>
> +             <number>4</number>
> +           </min>
> +         </iothreads>

IMHO this starts to be more useful than a simple yes|no, as it is
starting to express a concept where there are many possible right
answers.  More interesting would also be ideas about CPU pinning
and sched tuning

> +    -->
> +  </features>


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|