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@xxxxxxxxxx> > --- > 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfoRegards, 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 :|
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
