From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:43713)
	by lists.gnu.org with esmtp (Exim 4.71) (envelope-from <pl@kamp.de>)
	id 1ZhaXa-00021g-JW
	for qemu-devel@nongnu.org; Thu, 01 Oct 2015 05:52:43 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <pl@kamp.de>) id 1ZhaXX-0004Sl-8L
	for qemu-devel@nongnu.org; Thu, 01 Oct 2015 05:52:42 -0400
Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:52319 helo=mx01.kamp.de)
	by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from <pl@kamp.de>)
	id 1ZhaXW-0004SP-VS
	for qemu-devel@nongnu.org; Thu, 01 Oct 2015 05:52:39 -0400
Message-ID: <560D0260.4020305@kamp.de>
Date: Thu, 01 Oct 2015 11:52:32 +0200
From: Peter Lieven <pl@kamp.de>
MIME-Version: 1.0
References: <1443206217-6255-1-git-send-email-pl@kamp.de>	
	<1443522513.21557.18.camel@redhat.com>	
	<CC45B647-7488-4501-BB97-BE10E1295A22@kamp.de>	
	<1443530995.21557.24.camel@redhat.com>	
	<AD81571E-67EE-4DB2-822B-4BD9B16756C2@kamp.de>
	<1443535703.21557.63.camel@redhat.com>
In-Reply-To: <1443535703.21557.63.camel@redhat.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH V2] vnc: destroy server surface if no
	client is connected
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: qemu-devel@nongnu.org

Am 29.09.2015 um 16:08 schrieb Gerd Hoffmann:
>   Hi,
>
>> what about Recycling the output buffer as worker thread buffer?
> You can't do that as vs is allocated on the stack, therefore not valid
> any more when vnc_worker_thread_loop returns.
>
>
>> about shrinking: I had the idea to count the number of times the buffer was (significantly) too big and only shrink if that counter has reached a reasonable value. and reset that counter to zero if the buffer has the right size.
>>
>> i would check this in qio_buffer_resize. as you suggested earlier.
> Not sure whenever it is a good idea to do that on every reserve call.
> Maybe better place shrink calls in places where you know it is worth
> checking, to have lower overhead.
>
> Patches are welcome in any case ;)

Please have a look at:

https://github.com/plieven/qemu/tree/vnc-next-2.0

Peter