From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:47470) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2ktZ-0001jr-IX for qemu-devel@nongnu.org; Wed, 29 Feb 2012 09:52:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S2ktP-0006x3-9o for qemu-devel@nongnu.org; Wed, 29 Feb 2012 09:52:45 -0500 Received: from mx1.redhat.com ([209.132.183.28]:2028) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2ktP-0006wu-1f for qemu-devel@nongnu.org; Wed, 29 Feb 2012 09:52:35 -0500 Date: Wed, 29 Feb 2012 11:52:33 -0300 From: Luiz Capitulino Message-ID: <20120229115233.5baf259e@doriath.home> In-Reply-To: <4F4DD876.1080707@redhat.com> References: <1330118525-14522-1-git-send-email-alevy@redhat.com> <1330118525-14522-4-git-send-email-alevy@redhat.com> <4F4811CF.7050909@codemonkey.ws> <20120225084607.GA22687@garlic.redhat.com> <20120228171039.36c394a3@doriath.home> <4F4DD876.1080707@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 4/4] add qmp screendump-async List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: Alon Levy , armbru@redhat.com, Anthony Liguori , qemu-devel@nongnu.org On Wed, 29 Feb 2012 08:49:10 +0100 Gerd Hoffmann wrote: > Hi, > > >> There is a hang possible with the current screendump command, qxl, a > >> spice client using libvirt and spice-gtk such as virt-viewer / > >> remote-viewer, where you have: > >> 1. libvirt waiting for screendump to complete > >> 2. screendump waiting for spice server thread to render > >> 3. spice server thread waiting for spice client to read messages > > > > Which messages? > > spice protocol. > > >> 4. spice client == libvirt client, waiting for screendump completion > > > > The way I had understood this problem is that qxl takes a long time to > > perform a screen dump, which would cause the global mutex to be held for > > a long time. If this is really serious, then a async command for it > > makes sense IMO. > > That describes it pretty good. Normal workflow is that spice-server > sends the rendering commands received from the guest off to the spice > client and the actual rendering happens there. spice-server also keeps > track of the rendering commands so it can actually render on the host > side too of needed (called 'local rendering'). But it doesn't do that > unless it has to to avoid wasting cycles. Events which need local > rendering are: (1) display on sdl/vnc, (2) screendump monitor command, > (3) guest requesting screen content (happens when doing screen shots > for example). > > So when issuing the screendump monitor command we have to ask > spice-server to render the screen for us, when it is done we can write > out the screen dump. We don't want block the iothread while the spice > server is busy does the rendering. Anthony, the only way I can think of solving this is making the screendump asynchronous. Do you have a different suggestion? > > Additionally the local rendering can be delayed by a spice-client > connected via slow network link. This is (3) in alon's list above. > There are plans to fix that, but it isn't trivial to do due to the way > spice-server keeps track of the rendering commands. It can delay the > rendering several seconds. But even without that I've seen delays > around 50ms, which is still way too much to have iothread blocked. > > cheers, > Gerd >