On Tue, Feb 11, 2020 at 04:20:41PM +0000, Stefan Hajnoczi wrote: > 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
and that it's helpful for performance?