| Message ID | 1440670734-5616-3-git-send-email-pl@kamp.de |
|---|---|
| State | New |
| Headers | show |
On Thu, Aug 27, 2015 at 12:18:52PM +0200, Peter Lieven wrote: > currently the Buffer can only grow. This increases Qemu memory footprint > dramatically since normally the biggest VNC updates are at connection time. > But also after a VNC session has terminated there is one persistent buffer > in queue->buffer which I have seen to increase to over 100MB and it is never > getting smaller again. Do you have any idea what caused the buffer to increase to 100MB in size in the first place ? I would expect a full screen update would cause the biggest buffer usage, and even for a 1920x1140 screen that should not be anywhere near 100MB in size. IOW, i'm wondering if the 100MB usage is symptomatic of a more serious bug somewhere else in the VNC code that you're just masking you reducing buffer size afterwards. Regards, Daniel
Am 27.08.2015 um 12:39 schrieb Daniel P. Berrange: > On Thu, Aug 27, 2015 at 12:18:52PM +0200, Peter Lieven wrote: >> currently the Buffer can only grow. This increases Qemu memory footprint >> dramatically since normally the biggest VNC updates are at connection time. >> But also after a VNC session has terminated there is one persistent buffer >> in queue->buffer which I have seen to increase to over 100MB and it is never >> getting smaller again. > Do you have any idea what caused the buffer to increase to 100MB in size > in the first place ? I would expect a full screen update would cause the > biggest buffer usage, and even for a 1920x1140 screen that should not > be anywhere near 100MB in size. IOW, i'm wondering if the 100MB usage > is symptomatic of a more serious bug somewhere else in the VNC code > that you're just masking you reducing buffer size afterwards. Maybe my commit message was a bit unclear. The memory usage of all buffers went up to 100MB. The issue with the Buffer is that its not shrinking and that the date is effectivly in 3 Buffers before its transferred on the wire. Plus depending on the encoding used there are even more internal buffers. Peter
diff --git a/ui/vnc.c b/ui/vnc.c index 8cfd2d8..061e337 100644 --- a/ui/vnc.c +++ b/ui/vnc.c @@ -654,6 +654,7 @@ void vnc_framebuffer_update(VncState *vs, int x, int y, int w, int h, } #define BUFFER_MIN_INIT_SIZE 4096 +#define BUFFER_MIN_SHRINK_SIZE 65536 void buffer_reserve(Buffer *buffer, size_t len) { @@ -674,9 +675,19 @@ uint8_t *buffer_end(Buffer *buffer) return buffer->buffer + buffer->offset; } +static void buffer_shrink(Buffer *buffer) { + size_t new = MAX(pow2ceil(buffer->offset) * 2, + BUFFER_MIN_SHRINK_SIZE); + if (new < buffer->capacity) { + buffer->buffer = g_realloc(buffer->buffer, new); + buffer->capacity = new; + } +} + void buffer_reset(Buffer *buffer) { - buffer->offset = 0; + buffer->offset = 0; + buffer_shrink(buffer); } void buffer_free(Buffer *buffer) @@ -698,6 +709,7 @@ void buffer_advance(Buffer *buf, size_t len) memmove(buf->buffer, buf->buffer + len, (buf->offset - len)); buf->offset -= len; + buffer_shrink(buf); } static void vnc_desktop_resize(VncState *vs)
currently the Buffer can only grow. This increases Qemu memory footprint dramatically since normally the biggest VNC updates are at connection time. But also after a VNC session has terminated there is one persistent buffer in queue->buffer which I have seen to increase to over 100MB and it is never getting smaller again. Signed-off-by: Peter Lieven <pl@kamp.de> --- ui/vnc.c | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-)