On Mon, Feb 03, 2020 at 12:39:49PM +0100, Sergio Lopez wrote: > On Mon, Feb 03, 2020 at 10:57:44AM +0000, Daniel P. Berrangé wrote: > > On Mon, Feb 03, 2020 at 11:25:29AM +0100, Sergio Lopez wrote: > > > On Thu, Jan 30, 2020 at 10:52:35AM +0000, Stefan Hajnoczi wrote: > > > > On Thu, Jan 30, 2020 at 01:29:16AM +0100, Paolo Bonzini wrote: > > > > > On 29/01/20 16:44, Stefan Hajnoczi wrote: > > > > > > On Mon, Jan 27, 2020 at 02:10:31PM +0100, Cornelia Huck wrote: > > > > > >> On Fri, 24 Jan 2020 10:01:57 +0000 > > > > > >> Stefan Hajnoczi <stefa...@redhat.com> wrote: > > So I think we need to, at the very least, make a clear statement here > > about what tuning approach should be applied vCPU count gets high, > > and probably even apply that as a default out of the box approach. > > In general, I would agree, but in this particular case the > optimization has an impact on something outside's QEMU control (host's > resources), so we lack the information needed to make a proper guess. > > My main concern here is users upgrading QEMU to hit some kind of crash > or performance issue, without having touched their VM config. And
I don't think this is an issue since only newly created guests are affected. Existing machine types are unchanged. > let's not forget that Stefan said in the cover that this amounts to a > 1-4% improvement on 4k operations on an SSD, and I guess that's with > iodepth=1. I suspect with a larger block size and/or higher iodepth > the improvement will be barely noticeable, which means it'll only have > a positive impact on users running DB/OLTP or similar workloads on > dedicated, directly attached, low-latency storage. > > But don't get me wrong, this is a *good* optimization. It's just I > think we should play safe here. The NVMe card I've been testing has 64 queues. Let's keep the virtio limit roughly the same as real hardware. That way, multi-queue block layer support in QEMU will be able to fully exploit the hardware (similar to how we size request queues to be larger than the common 64 /sys/block/FOO/queue/nr_requests). The point of this change is to improve performance on SMP guests. Setting the limit to 4-8 is too low, since it leaves guests that most need this optimization with a sub-optimal configuration. I will create a 32 vCPU guest with 100 virtio-blk devices and verify that enabling multi-queue is successful. Stefan
signature.asc
Description: PGP signature
