Hi,
I think the hardcoded limit was intended for limiting the occupancy of
the dev ram with drawables that are referenced by the display channel.
If the limit is reasonable it should help with keeping allocations in
the driver fluent, and avoiding IO_OOM.
An alternative approach is to monitor the actual size that is currently
occupied by drawables that are referenced by the display channel, and to
limit *this* size, instead of the number of drawables. In fact, I've
been lately working on such approach + improving the timing of releasing
resources. My code doesn't remove the hardcoded NUM_DRAWABLES limit, but
I think that after I post it, it will be safer to remove this limit.
However, it is not that straight-forward to estimate the occupancy of
the devram on the server side, since, for example, we don't know the
size of the drawables that are pending in the cmd-ring. Also, the
Windows driver has its own cache, and different drawables may share the
same memory (while I don't think the Linux driver does the same).
About the rendering on the server side, as Marc-André noted, at some
point, whether it is when the client connects, or when the memory limit
is reached, the drawables need to be rendered. The number of drawables
that will be rendered depends on their layout and if they cover one
another, so that hidden drawables can be dropped.
Cheers,
Yonit.
On 10/09/2013 08:31 AM, Dietmar Maurer wrote:
I just detected that my simple spiceterm generates more than
1000 drawables, so alloc_drawable() always fail.
The effect is that I always draw twice (on server and at client)!
This is an area I am newbie ;)
Isn't the server always drawing anyway at some point?
No. There is no need to draw anything at the server side (for spiceterm).
Isnt't the 1000 drawables limit just slowing down the caller (guest/vm side), to
leave time for clients to process all drawables in the pipes.
no, it leads to additional draw commands on the server side. So this is a waste
of computing power.
What alternative do you propose?
NUM_DRAWABLES=3000
but I guess that can have a negative performance impact elsewhere?
I guess one would see the same effect when running a xterm inside a
VM, because
a terminal has a size of 80x25 characters, which gives 2000 different
regions.
What is the suggested way to avoid such things?
I'll let someone else reply suggestion, as I don't know myself.
Also, I don’t think I need the rendered content on the server side for
spiceterm (why?).
So is it possible to disable server side rendering at all?
If you don't have client connected or for reconnection, you still want complete
rendering ready, no?
No, I do not really need that. spiceterm only allows a single connection.
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel
_______________________________________________
Spice-devel mailing list
Spice-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/spice-devel