On Wed, 29 Feb 2012 08:49:10 +0100 Gerd Hoffmann <kra...@redhat.com> 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 >
