public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: David Chiluk <dave.chiluk@canonical.com>
To: Rafael Tinoco <rafael.tinoco@canonical.com>, paulmck@linux.vnet.ibm.com
Cc: linux-kernel@vger.kernel.org, davem@davemloft.net,
	ebiederm@xmission.com,
	Christopher Arges <chris.j.arges@canonical.com>,
	Jay Vosburgh <jay.vosburgh@canonical.com>
Subject: Re: Possible netns creation and execution performance/scalability regression since v3.8 due to rcu callbacks being offloaded to multiple cpus
Date: Wed, 11 Jun 2014 10:46:00 -0500	[thread overview]
Message-ID: <539879B8.4010204@canonical.com> (raw)
In-Reply-To: <CAJE_dJwfaUkop=XZxD-BfDPwKDjnfF1bvmD6XWaqVA4Xt2E6bQ@mail.gmail.com>

On 06/11/2014 10:17 AM, Rafael Tinoco wrote:
> This script simulates a failure on a cloud infrastructure, for ex. As soon as
> one virtualization host fails all its network namespaces have to be migrated
> to other node. Creating thousands of netns in the shortest time possible
> is the objective here. This regression was observed trying to migrate from
> v3.5 to v3.8+.
> 
> Script creates up to 3000/4000 thousands network namespaces and places
> links on them. Every 250 mark (netns already created) we have a throughput
> average (how many were created per second up from last mark to this one).

Here's a little more background, and the "why it matters".

In an openstack cloud, neutron *(openstack's networking framework) keeps
all customers of the cloud separated via network namespaces.  On each
compute node this is not a big deal, since each compute node can only
handle at most a few hundred VMs.  However in order for neutron to route
a customer's network traffic between disparate compute hosts, it uses
the concept of a neutron gateway.  In order for customer A's vm on host
1 to talk to customer A's vm on host 2, it must first go through a gre
tunnel to the neutron gateway.  The Neutron gateay then turns around and
routes the network traffic over another gre tunnel to host 2.  The
neutron gateway is where the problem is.

The neutron gateway must have a network namespace for every net
namespace in the cloud.  Granted this collection can be split up by
increasing the number of neutron gateways *(scaling out), but some
clouds have decided to run these gateways on very beefy machines.  As
you can see by the graph, there is a software limitation that prevents
these machines from hosting any more than a few thousand namespaces.
This makes the gateway's hardware severely under-utilized.

Now think about what happens when a gateway goes down, the namespaces
need to be migrated, or a new machine needs to be brought up to replace
it.  When we're talking about 3000 namespaces, the amount of time it
takes simply to recreate the namespaces becomes very significant.

The script is a stripped down example of what exactly is being done on
the neutron gateway in order to create namespaces.

Dave.


  reply	other threads:[~2014-06-11 15:46 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-11  5:52 Possible netns creation and execution performance/scalability regression since v3.8 due to rcu callbacks being offloaded to multiple cpus Rafael Tinoco
2014-06-11  7:07 ` Eric W. Biederman
2014-06-11 13:39 ` Paul E. McKenney
2014-06-11 15:17   ` Rafael Tinoco
2014-06-11 15:46     ` David Chiluk [this message]
2014-06-11 16:18       ` Paul E. McKenney
2014-06-11 18:27         ` Dave Chiluk
2014-06-11 19:48           ` Paul E. McKenney
2014-06-11 20:55             ` Eric W. Biederman
2014-06-11 21:03               ` Rafael Tinoco
2014-06-11 20:46           ` Eric W. Biederman
2014-06-11 21:14             ` Dave Chiluk
2014-06-11 22:52             ` Paul E. McKenney
2014-06-11 23:12               ` Eric W. Biederman
2014-06-11 23:49                 ` Paul E. McKenney
2014-06-12  0:14                   ` Eric W. Biederman
2014-06-12  0:25                     ` Rafael Tinoco
2014-06-12  1:09                       ` Eric W. Biederman
2014-06-12  1:14                         ` Rafael Tinoco
     [not found]                           ` <CAJE_dJzjcWP=e_CPM1M64URVHiEFFb+fP6g2YKZVdoFntkQMZg@mail.gmail.com>
2014-06-13 18:22                             ` Rafael Tinoco
2014-06-14  0:02                             ` Eric W. Biederman
2014-06-16 15:01                               ` Rafael Tinoco
2014-07-17 12:05                                 ` Rafael David Tinoco
2014-07-24  7:01                                   ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=539879B8.4010204@canonical.com \
    --to=dave.chiluk@canonical.com \
    --cc=chiluk@canonical.com \
    --cc=chris.j.arges@canonical.com \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=jay.vosburgh@canonical.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=rafael.tinoco@canonical.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox