From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:54812) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2H9s-0007nQ-Q7 for qemu-devel@nongnu.org; Wed, 02 Jul 2014 05:49:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X2H9k-000486-JD for qemu-devel@nongnu.org; Wed, 02 Jul 2014 05:48:56 -0400 Received: from mx1.redhat.com ([209.132.183.28]:11017) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2H9k-000480-9w for qemu-devel@nongnu.org; Wed, 02 Jul 2014 05:48:48 -0400 Message-ID: <53B3D579.3090500@redhat.com> Date: Wed, 02 Jul 2014 11:48:41 +0200 From: Paolo Bonzini MIME-Version: 1.0 References: <53ADE769.3060903@redhat.com> <20140630080850.GB30969@stefanha-thinkpad.redhat.com> <53B2E69A.1090707@redhat.com> <20140702085453.GI4660@stefanha-thinkpad.redhat.com> <53B3CD3C.4040506@redhat.com> <20140702093930.GF5996@noname.str.redhat.com> In-Reply-To: <20140702093930.GF5996@noname.str.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [regression] dataplane: throughout -40% by commit 580b6b2aa2 List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Fam Zheng , "Michael S. Tsirkin" , Ming Lei , qemu-devel , Stefan Hajnoczi , Stefan Hajnoczi Il 02/07/2014 11:39, Kevin Wolf ha scritto: > Am 02.07.2014 um 11:13 hat Paolo Bonzini geschrieben: > I don't think starting with that fast path as _the_ solution is a good > idea. It would essentially restrict dataplane to the scenarios that used > to work well in 2.0 - just look at what the block.c read/write functions > do: no image formats, (almost?) no block jobs, no 4k sector support, no > writethrough mode, no zero detection, no throttling, no nothing. > Anything we want to keep while using the fast path we would have to > duplicate there. You're entirely right (I wouldn't duplicate it though, I would just sacrifice it). But I think none of the bullets apply in maximum performance situations, and fast paths are okay as long as they are picked dynamically at run-time. >>> Another idea is to skip aio_notify() when we're sure the event loop >>> isn't blocked in g_poll(). Doing this is a thread-safe and lockless way >>> might be tricky though. >> >> Yes, good idea for 2.2 but not now. > > Isn't it a first approximation that it's unnecessary when we're already > running in the thread with the AIO main loop? (Which pretty much means > always with dataplane.) Or can it be required even when we don't switch > to a different thread? That's not even that much of an approximation. I think it's pretty much the definition of when it's unnecessary. Clever! An approximation is "it's unnecessary if we have the aio context lock taken". Which is also always the case with dataplane, but never with non-dataplane (the main loop bypasses aio_context_acquire/release). Adding rfifolock_is_owned is trivial. Paolo