[Spice-devel] [PATCH spice] spicec: Do not try to do accounting of pci memory

[Hans de Goede]

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