Hi,
On 10/11/2010 10:22 AM, Gerd Hoffmann wrote:
Hi,
This patch fixes this by simply removing the
"attempted" pci memory accounting. As there is no
need for that, as the driver already must keep
track of pci memory usage.
Is this actually about pci memory?
Well the X11 client calculates the glz_window_size based
on the pci memory size / 2.
Note the calculating of the glz_window_size in
red_client.cpp cannot be removed as the calculated
value is send as part of the SpiceMsgcDisplayInit on
connect.
I think this is more about how much memory the client is willing to spend for
the glz window.
Right, but for some reason this gets derived from the
pci memory size.
The server needs to take care when encoding the bits, thats why the client
passes the size in the init message.
Right, what was happening is:
The X11 client keeps track of the (uncompressed) size of
all images in the glz window, and if that exceeds 1.5
times the glz_window_size it specified in the
SpiceMsgcDisplayInit, it waits for the glz_window to
shrink before continuing (which never happens, as
no new glz_window images which could shrink it
by moving the head are received until the current
one is handled).
The 1.5 factor which was present in this check is rather
fishy so I guess this problem has been hit before
and never thoroughly analyzed. I've the feeling the
server is doing accounting of the compressed size,
where as the client was doing uncompressed size
accounting. But since the server already does accounting
the client side accounting can be simply removed.
The PCI memory might be another server-side constraint, but that is nothing the
client has to worry about.
Right.
The accounding is not needed indeed. The server informs the client about the
oldest image it will use for glz references, anything older can be released by
the client, there is no need to keep track of the memory consumption on the
client side.
That is my analysis too.
Nevertheless the hanging client might point to a server (or guest driver?) side
issue though. Maybe the server uses a larger glz window than the client is
willing to allow, which in turn trips up the client side accounting?
The server is writing more (uncompressed) data the the glz window size
specified by the client, but
it is keeping it within reasonable limits. As said I think the problem has
to do with uncompressed versus compressed accounting, that would also
explain the 1.5 factor already present in the current client code check.
Thanks & Regards,
Hans
_______________________________________________
Spice-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/spice-devel
