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.