From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:43113) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXVss-0007cm-Sf for qemu-devel@nongnu.org; Thu, 03 Sep 2015 10:53:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZXVsp-0000Nm-Mt for qemu-devel@nongnu.org; Thu, 03 Sep 2015 10:53:02 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:48617 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZXVsp-0000MT-7i for qemu-devel@nongnu.org; Thu, 03 Sep 2015 10:52:59 -0400 References: <1440670734-5616-1-git-send-email-pl@kamp.de> <1440670734-5616-3-git-send-email-pl@kamp.de> <20150827103951.GN24486@redhat.com> <1441273974.557.19.camel@redhat.com> <55E81BED.1080701@kamp.de> <1441281131.557.56.camel@redhat.com> From: Peter Lieven Message-ID: <55E85EC7.70906@kamp.de> Date: Thu, 3 Sep 2015 16:52:55 +0200 MIME-Version: 1.0 In-Reply-To: <1441281131.557.56.camel@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/4] vnc: allow the Buffer to shrink again List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gerd Hoffmann Cc: qemu-devel@nongnu.org Am 03.09.2015 um 13:52 schrieb Gerd Hoffmann: > Hi, > >>> Beside that I think it makes sense to have the shrinking logic in >>> buffer_reserve too so we don't have to add buffer_shrink calls all over >>> the place. >> We need a possibility to shrink the buffer after it has been used. >> Especially the queue->buffer. > That works fine. Test patch attached. Not completely. queue->buffer may remain big, if you disconnect in the wrong moment. Maybe there should be a buffer_free if the last client disconnects? In general I like your modified patch because the shrinking is slower than in my version. for 64*1024 you should introduce a macro. > > I'm not sure this is the way to go though. I see alot of growing and > shrinking. We also do alot of coping (each realloc, but also from > buffer to buffer). > > We might be better off redoing the whole buffer management, at least > once we are done with encoding one frame. Passing on a *pointer* to the > buffer, once sent to the wire just free the buffer. Allocate a new one > for the next frame. That way we copy around less data and also don't > have to worry about big unused buffers in the first place ... Maybe this should be the permanent solution. Peter