|
From: | Peter Lieven |
Subject: | Re: [Qemu-devel] [PATCH 2/4] vnc: allow the Buffer to shrink again |
Date: | Thu, 3 Sep 2015 12:36:50 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 |
Am 03.09.2015 um 11:52 schrieb Gerd Hoffmann:
On Do, 2015-08-27 at 11:39 +0100, Daniel P. Berrange wrote: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.Cooked up a buffer stats patch (attached). Buffer sizes are nowhere near 100MB for me (as expected by Daniel). Individual buffers are in the 1 -> 4 MB range (1920x1080), even summed up this is more like 10 not 100 MB. So, big question remains why they are that big for you?
Simple case to create at least a reasonable allocation: -vga vmware and a client that prefers Hextile encoding. ~/git/qemu$ x86_64-softmmu/qemu-system-x86_64 -m 4096 -enable-kvm -cdrom ~/Downloads/ubuntu-14.04.3-desktop-amd64.iso -k de -usb -device usb-tablet -nodefaults -serial null -parallel null -cpu Westmere,enforce -vga vmware -monitor stdio -vnc :0 QEMU 2.4.50 monitor - type 'help' for more information (qemu) buffer_reserve: 11/out : 4 kB buffer_reserve: 11/in : 4 kB buffer_reserve: queue : 4 kB buffer_reserve: queue : 8 kB buffer_reserve: 11/jobs : 8 kB buffer_reserve: 11/out : 16 kB buffer_reserve: queue : 16 kB buffer_reserve: queue : 32 kB buffer_reserve: queue : 64 kB buffer_reserve: queue : 128 kB buffer_reserve: queue : 256 kB buffer_reserve: 11/jobs : 256 kB buffer_reserve: 11/out : 256 kB buffer_reserve: queue : 512 kB buffer_reserve: queue : 1024 kB buffer_reserve: queue : 2048 kB buffer_reserve: 11/jobs : 2048 kB buffer_reserve: 11/out : 2048 kB buffer_reserve: queue : 4096 kB buffer_reserve: queue : 8192 kB buffer_reserve: queue : 16384 kB buffer_reserve: 11/jobs : 16384 kB buffer_reserve: 11/out : 16384 kB Its not 100MB, but 50MB. Same with Tight encoding: (qemu) buffer_reserve: 11/out : 4 kB buffer_reserve: 11/in : 4 kB buffer_reserve: queue : 4 kB buffer_reserve: 11/t-tight: 4 kB buffer_reserve: 11/t-tight: 8 kB buffer_reserve: 11/t-tight: 16 kB buffer_reserve: 11/t-tight: 32 kB buffer_reserve: 11/t-tight: 64 kB buffer_reserve: 11/t-tight: 128 kB buffer_reserve: 11/t-tight: 256 kB buffer_reserve: 11/t-tight: 512 kB buffer_reserve: 11/t-zlib : 4 kB buffer_reserve: 11/jobs : 4 kB buffer_reserve: 11/t-zlib : 64 kB buffer_reserve: 11/t-tight: 1024 kB buffer_reserve: 11/t-tight: 2048 kB buffer_reserve: 11/t-tight: 4096 kB buffer_reserve: 11/t-tight: 8192 kB buffer_reserve: 11/t-tight: 16384 kB buffer_reserve: 11/t-zlib : 128 kB buffer_reserve: queue : 8 kB buffer_reserve: 11/jobs : 8 kB buffer_reserve: 11/out : 8 kB buffer_reserve: 11/t-zlib : 256 kB buffer_reserve: queue : 64 kB buffer_reserve: queue : 128 kB buffer_reserve: queue : 256 kB buffer_reserve: queue : 512 kB buffer_reserve: queue : 1024 kB buffer_reserve: queue : 2048 kB buffer_reserve: queue : 4096 kB buffer_reserve: queue : 8192 kB buffer_reserve: 11/jobs : 8192 kB buffer_reserve: 11/out : 8192 kB ~40MB. Peter
[Prev in Thread] | Current Thread | [Next in Thread] |