From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33461) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMxMl-0001WW-98 for qemu-devel@nongnu.org; Tue, 02 Apr 2013 05:18:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UMxMg-0000Ny-Kd for qemu-devel@nongnu.org; Tue, 02 Apr 2013 05:18:55 -0400 Received: from mx1.redhat.com ([209.132.183.28]:55920) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UMxMg-0000Nk-D7 for qemu-devel@nongnu.org; Tue, 02 Apr 2013 05:18:50 -0400 Message-ID: <515AA273.1000109@redhat.com> Date: Tue, 02 Apr 2013 11:18:43 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1364240439-23450-1-git-send-email-lcapitulino@redhat.com> <1364240439-23450-3-git-send-email-lcapitulino@redhat.com> <515295A1.8030705@linux.vnet.ibm.com> In-Reply-To: <515295A1.8030705@linux.vnet.ibm.com> Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 2/2] Monitor: Make output buffer dynamic List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Wenchao Xia Cc: fred.konrad@greensocs.com, qemu-devel@nongnu.org, Luiz Capitulino On 03/27/13 07:45, Wenchao Xia wrote: > Hi, Luiz > Personally I hope reduce the dynamic allocated buffer which brings > fragments and unexpected memory grow. It's a tradeoff. We can reduce the dynamic allocation, by simply reusing the qstring instead of allocation a new one (after complete/partial write). At the cost of wasting some memory. Given that qstrings grow expotentially I think the dynamic allocation overhead isn't that bad. > Instead, how about sacrifice > some time to wait output complete, since monitor is not time critical? The watch added recently will fire when there is space for writing. Right now it will write out the next chunk from the buffer. In theory we could change the monitor code to continue generating the response when there is more output space, so we don't have to buffer it in the first place. But I think the complexity simply isn't worth it for the memory savings we can gain. cheers, Gerd