[Libosinfo] [osinfo-db PATCH 1/3] workload: Add high performance
Martin Kletzander
mkletzan at redhat.com
Fri Nov 23 13:48:31 UTC 2018
On Tue, Nov 20, 2018 at 04:12:05PM +0000, Daniel P. Berrangé wrote:
>On Tue, Nov 20, 2018 at 03:44:51PM +0000, Daniel P. Berrangé wrote:
>> 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.
>>
Yes, however each new mgmt app needs to hardcode this. If they use libosinfo,
then the codepath for "what's better" could be just part of the libosinfo usage.
>> 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 ?
>
>Or are these devices supposed to indicate a white list ?
>
>ie refuse to install the guest if it doesn't support
>virtio-blk ?
>
Yes, basically what I see from this is three possible usages:
1) If someone selects a "high-perf" profile with, let's say with windows, it
will fail unless there are virtio drivers installed (that's part of the
windows XML, IIRC). For some older ones it will fail to find a device.
2) The mgmt application can suggest to make a change so that it matches this
workload. Let's say you select Fedora 28, high-perf and then try to change
some device model (and let's say it allows that even if it doesn't match the
workload). It can then tell you "hey look, you might want to select virtio
instead" or "this configuration will use virtio-0.9, but to match the
high-perf profile you need to do this and this change to use virtio-1.0"
3) Or the sole purpose of derivation from other workloads so that the most
common performance data are not duplicated everywhere.
>> If anything following the workload recommendation would be a
>> step backwards because it is KVM specific, not considering
>> the Xen paravirt devices.
>>
I thought of it similarly to what I understand the "deployment" does. You are
trying to create a subset of supported devices between the platform and os. And
this would allow you to just throw the workload into the mix as well.
>>
>> > 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
>>
Yeah, that could be helpful as well.
>> > + -->
>> > + </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 :|
>>
>> _______________________________________________
>> Libosinfo mailing list
>> Libosinfo at redhat.com
>> https://www.redhat.com/mailman/listinfo/libosinfo
>
>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 :|
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Digital signature
URL: <http://listman.redhat.com/archives/libosinfo/attachments/20181123/73551a02/attachment.sig>
More information about the Libosinfo
mailing list