From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55670) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNIbY-0007uW-2x for qemu-devel@nongnu.org; Wed, 13 Jul 2016 07:45:28 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bNIbU-0006ET-UV for qemu-devel@nongnu.org; Wed, 13 Jul 2016 07:45:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53719) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNIbU-0006EO-Oe for qemu-devel@nongnu.org; Wed, 13 Jul 2016 07:45:24 -0400 Date: Wed, 13 Jul 2016 13:45:20 +0200 From: Kevin Wolf Message-ID: <20160713114520.GC5548@noname.redhat.com> References: <20160713022334.GB16038@ad.usersys.redhat.com> <1468396629-26094-1-git-send-email-roman.penyaev@profitbricks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Subject: Re: [Qemu-devel] [PATCH V2 1/1] linux-aio: prevent submitting more than MAX_EVENTS List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Roman Penyaev Cc: Paolo Bonzini , Fam Zheng , Stefan Hajnoczi , qemu-devel Am 13.07.2016 um 13:33 hat Roman Penyaev geschrieben: > Just to be sure that we are on the same page: > > 1. We have this commit "linux-aio: Cancel BH if not needed" which > > a) introduces performance regression on my fio workloads on the > following config: "iothread=1, VCPU=8, MQ=8". Performance > dropped from 1878MB/s to 1606MB/s with Stefan's fix, that is > ~14%. Do we already understand why the performance regresses with the patch? As long as we don't, everything we do is just guesswork. Kevin > b) reproduces IO hang, because of in-flights > MAX_EVENTS. > > So probably this commit should be reverted because of a) not b). > > 2. Stefan has fix for 1.b) issue repeating io_getevents(), which > is obviously an excess for generic cases where MQ=1 (queue depth > for virtio_blk is also set to 128 i.e. equal to MAX_EVENTS on > QEMU side). > > 3. The current patch also aims to fix 1.b) issue restricting number > of in-flights. > > > Reverting 1. will fix all the problems, without any need to apply > 2. or 3. The most lazy variant. > > Restricting in-flights is also a step forward, since submitting > till -EAGAIN is also possible, but leads (as we already know) to > IO hang on specific loads and conditions. > > But 2. and 3. are mutual exclusive and should not be applied > together. > > So we have several alternatives and a choice what to follow. > > -- > Roman