[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090129213549.7fadfa2e@extreme>
Date: Thu, 29 Jan 2009 21:35:49 -0800
From: Stephen Hemminger <shemminger@...tta.com>
To: "Daniel P. Berrange" <berrange@...hat.com>,
Fedora/Linux Management Tools <et-mgmt-tools@...hat.com>,
David Miller <davem@...emloft.net>,
Evgeniy Polyakov <zbr@...emap.net>
Cc: berrange@...hat.com,
Fedora/Linux Management Tools <et-mgmt-tools@...hat.com>,
netdev@...r.kernel.org
Subject: virt-manager broken by bind(0) in net-next.
On Thu, 29 Jan 2009 10:35:44 +0000
"Daniel P. Berrange" <berrange@...hat.com> wrote:
> On Wed, Jan 28, 2009 at 09:21:14PM -0800, Stephen Hemminger wrote:
> > This is probably related to the new GEM code. But on 2.6.29-rc2 if I start up the virtual
> > machine manager then run a guest, the display gets screwed up.
> >
> > virt-machine-manager
> > click local-host (System)
> > Run one of the existing VM's
> >
> > The virtual console window then cause a dialog about allowing remote access to display;
> > (this never happened with earlier kernels), regression #1
> >
> > Then if I allow it multiple copies of the window start cloning and general chaos ensues.
>
> You'll have to provide more useful information than 'screwed up' and
> 'general choas' if we're to properly dianose this. A screenshot of what
> is wrong if there's a graphics rendering problem would be a start.
>
> Also, what GTK-VNC version do you have ? Make sure it is at least
> 0.3.8, so that it is using Cairo for rendering, and not old buggy
> OpenGL based GtkGLExt.
>
> Daniel
The problem is only in the net-next tree (not mainline 2.6.29-rcX).
Bisected down to this commit is the problem:
a9d8f9110d7e953c2f2b521087a4179677843c2a is first bad commit
commit a9d8f9110d7e953c2f2b521087a4179677843c2a
Author: Evgeniy Polyakov <zbr@...emap.net>
Date: Mon Jan 19 16:46:02 2009 -0800
inet: Allowing more than 64k connections and heavily optimize bind(0) time.
With simple extension to the binding mechanism, which allows to bind more
than 64k sockets (or smaller amount, depending on sysctl parameters),
we have to traverse the whole bind hash table to find out empty bucket.
And while it is not a problem for example for 32k connections, bind()
completion time grows exponentially (since after each successful binding
we have to traverse one bucket more to find empty one) even if we start
each time from random offset inside the hash table.
So, when hash table is full, and we want to add another socket, we have
to traverse the whole table no matter what, so effectivelly this will be
the worst case performance and it will be constant.
Attached picture shows bind() time depending on number of already bound
sockets.
Not sure why but it breaks VNC, see attached screenshot.
Download attachment "Screenshot.png" of type "image/png" (178001 bytes)
Powered by blists - more mailing lists