From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1I2k0W-0002Pv-K4 for qemu-devel@nongnu.org; Mon, 25 Jun 2007 04:33:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1I2k0T-0002PT-3o for qemu-devel@nongnu.org; Mon, 25 Jun 2007 04:33:12 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1I2k0T-0002PQ-0u for qemu-devel@nongnu.org; Mon, 25 Jun 2007 04:33:09 -0400 Received: from mx1.actcom.co.il ([192.114.47.64] helo=smtp1.actcom.co.il) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1I2k0S-0006Xp-Cq for qemu-devel@nongnu.org; Mon, 25 Jun 2007 04:33:08 -0400 Received: from [10.0.0.13] (line25-90.adsl.actcom.co.il [192.115.25.90]) by smtp1.actcom.co.il (8.13.3/8.13.3) with ESMTP id l5P8X0XO018961 for ; Mon, 25 Jun 2007 11:33:04 +0300 Message-ID: <467F7CC6.6000207@codefidence.com> Date: Mon, 25 Jun 2007 11:28:54 +0300 From: Gilad Ben-Yossef MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] starting qemu vnc session on a pre-allocated port References: <467E6C25.3010908@codefidence.com> <467E7AB0.1000909@codemonkey.ws> <467EE5E0.5010605@codefidence.com> <467EF2D6.90501@codemonkey.ws> In-Reply-To: <467EF2D6.90501@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Hi Anthony, Thanks for the feedback. I'm afraid I'm to blame for the idea to this patch (but Shahar was the one that actually did the real work, I'm just bothering him). Anthony Liguori wrote: >> >> The problem with the solution you suggest is that all VNC traffic will >> be first sent to the unix domain socket, and then copied to the TCP >> socket. This double work may be acceptable if we're talking about one >> instance of qemu, but as I said, I run many concurrent sessions which >> create too much load. In the solution I suggest, this extra copying is >> not needed. > > > You're optimizing prematurely. The overhead of the copy is negligible > for something like VNC. Under normal circumstances, we're talking about > 30-100k/s. During idle usage, the bandwidth drops to almost nothing. > There are also the double context switches, more file descriptors and extra proccess to handle the copy but you are abosutly right - we have no indication what so ever that this really has any measurable impact on perfomance. I guess it's easier to resort to perfomance as an excuse since it involves things you can measure (even if they are meaningless) rather then trying to justify a design decision because it simply looks better. ;-) I'll try to do just that, anyway: Using Unix domain sockets would require adding extra code in some other proccess that will handle the socket to socket transfer. About 15 lines of code that must be running for as long as qemu does to handle the communication. That code still needs to be mnaintained, seperate from qemu, by anyone that trying to do something similar (so we have sync problems etc.) On the other hand, the change to qemu is ~5 lines (option parsing not included ;-) It's initaliation code only (no suprises mid run) and is maintained as part of qemu with exact same functionality. If you think users other then us will use the patch (and we believe they will), we think it'll be useful for this to be included in qemu mainline. Anyway, thanks for reading this long email and for qemu VNC support in general :-) Cheers, Gilad -- Gilad Ben-Yossef Codefidence. A name you can trust(tm) http://www.codefidence.com Phone: +972.3.7515563 ext. 201 | Cellular: +972.52.8260388 SIP: gilad@pbx.codefidence.com | Fax: +972.3.7515503 Lacking fins or tail the gefilte fish swims with great difficulty. -- A Jewish Haiku