From: ebiederm@xmission.com (Eric W. Biederman)
To: Rafael Tinoco <rafael.tinoco@canonical.com>
Cc: Paul McKenney <paulmck@linux.vnet.ibm.com>,
Dave Chiluk <chiluk@canonical.com>,
linux-kernel@vger.kernel.org, davem@davemloft.net,
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: Fri, 13 Jun 2014 17:02:37 -0700 [thread overview]
Message-ID: <87wqckqrxe.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <CAJE_dJzjcWP=e_CPM1M64URVHiEFFb+fP6g2YKZVdoFntkQMZg@mail.gmail.com> (Rafael Tinoco's message of "Fri, 13 Jun 2014 15:14:10 -0300")
Rafael Tinoco <rafael.tinoco@canonical.com> writes:
> Okay,
>
> Tests with the same script were done.
> I'm comparing : master + patch vs 3.15.0-rc5 (last sync'ed rcu commit)
> and 3.9 last bisect good.
>
> Same tests were made. I'm comparing the following versions:
>
> 1) master + suggested patch
> 2) 3.15.0-rc5 (last rcu commit in my clone)
> 3) 3.9-rc2 (last bisect good)
I am having a hard time making sense of your numbers.
If I have read your email correctly my suggested patch caused:
"ip netns add" numbers to improve
1x "ip netns exec" to improve some
2x "ip netns exec" to show no improvement
"ip link add" to show no effect (after the 2x ip netns exec)
This is interesting in a lot of ways.
- This seems to confirm that the only rcu usage in ip netns add
was switch_task_namespaces. Which is convinient as that rules
out most of the network stack when looking for performance oddities.
- "ip netns exec" had an expected performance improvement
- "ip netns exec" is still slow (so something odd is still going on)
- "ip link add" appears immaterial to the performance problem.
It would be interesting to switch the "ip link add" and "ip netns exec"
in your test case to confirm that there is nothing interesting/slow
going on in "ip link add"
Which leaves me with the question what ip "ip netns exec" remains
that is using rcu and is slowing all of this down.
Eric
> master + sug patch 3.15.0-rc5 (last rcu) 3.9-rc2 (bisec good)
> mark no none all no none all no
>
> # (netns add) / sec
>
> 250 125.00 250.00 250.00 20.83 22.73 50.00 83.33
> 500 250.00 250.00 250.00 22.73 22.73 50.00 125.00
> 750 250.00 125.00 125.00 20.83 22.73 62.50 125.00
> 1000 125.00 250.00 125.00 20.83 20.83 50.00 250.00
> 1250 125.00 125.00 250.00 22.73 22.73 50.00 125.00
> 1500 125.00 125.00 125.00 22.73 22.73 41.67 125.00
> 1750 125.00 125.00 83.33 22.73 22.73 50.00 83.33
> 2000 125.00 83.33 125.00 22.73 25.00 50.00 125.00
>
> -> From 3.15 to patched tree, netns add performance was ***
> restored/improved *** OK
>
> # (netns add + 1 x exec) / sec
>
> 250 11.90 14.71 31.25 5.00 6.76 15.63 62.50
> 500 11.90 13.89 31.25 5.10 7.14 15.63 41.67
> 750 11.90 13.89 27.78 5.10 7.14 15.63 50.00
> 1000 11.90 13.16 25.00 4.90 6.41 15.63 35.71
> 1250 11.90 13.89 25.00 4.90 6.58 15.63 27.78
> 1500 11.36 13.16 25.00 4.72 6.25 15.63 25.00
> 1750 11.90 12.50 22.73 4.63 5.56 14.71 20.83
> 2000 11.36 12.50 22.73 4.55 5.43 13.89 17.86
>
> -> From 3.15 to patched tree, performance improves +100% but still -
> 50% of 3.9-rc2
>
> # (netns add + 2 x exec) / sec
>
> 250 6.58 8.62 16.67 2.81 3.97 9.26 41.67
> 500 6.58 8.33 15.63 2.78 4.10 9.62 31.25
> 750 5.95 7.81 15.63 2.69 3.85 8.93 25.00
> 1000 5.95 7.35 13.89 2.60 3.73 8.93 20.83
> 1250 5.81 7.35 13.89 2.55 3.52 8.62 16.67
> 1500 5.81 7.35 13.16 0.00 3.47 8.62 13.89
> 1750 5.43 6.76 13.16 0.00 3.47 8.62 11.36
> 2000 5.32 6.58 12.50 0.00 3.38 8.33 9.26
>
> -> Same as before.
>
> # netns add + 2 x exec + 1 x ip link to netns
>
> 250 7.14 8.33 14.71 2.87 3.97 8.62 35.71
> 500 6.94 8.33 13.89 2.91 3.91 8.93 25.00
> 750 6.10 7.58 13.89 2.75 3.79 8.06 19.23
> 1000 5.56 6.94 12.50 2.69 3.85 8.06 14.71
> 1250 5.68 6.58 11.90 2.58 3.57 7.81 11.36
> 1500 5.56 6.58 10.87 0.00 3.73 7.58 10.00
> 1750 5.43 6.41 10.42 0.00 3.57 7.14 8.62
> 2000 5.21 6.25 10.00 0.00 3.33 7.14 6.94
>
> -> Ip link add to netns did not change performance proportion much.
>
> # netns add + 2 x exec + 2 x ip link to netns
>
> 250 7.35 8.62 13.89 2.94 4.03 8.33 31.25
> 500 7.14 8.06 12.50 2.94 4.03 8.06 20.83
> 750 6.41 7.58 11.90 2.81 3.85 7.81 15.63
> 1000 5.95 7.14 10.87 2.69 3.79 7.35 12.50
> 1250 5.81 6.76 10.00 2.66 3.62 7.14 10.00
> 1500 5.68 6.41 9.62 3.73 6.76 8.06
> 1750 5.32 6.25 8.93 3.68 6.58 7.35
> 2000 5.43 6.10 8.33 3.42 6.10 6.41
>
> -> Same as before.
>
> OBS:
>
> 1) It seems that performance got improved for network namespace
> addiction but maybe there can be some improvement also on netns
> execution. This way we might achieve same performance as 3.9.0-rc2
> (good bisect) had.
>
> 2) These tests were made with 4 cpu only.
>
> 3) Initial charts showed that 1 cpu case with all cpus as no-cb
> (without this patch) had something like 50% of bisect good. The 4 cpu
> (nocball) case had 26% of bisect good (like showed above in the last
> case -> 31.25 -- 8.33).
>
> 4) With the patch, using 4 cpus and nocball, we now have 44% of bisect
> good performance (against 26% we had).
>
> 5) NOCB_* is still an issue. It is clear that only NOCB_CPU_ALL option
> is giving us something near last good commit performance.
>
> Thank you
>
> Rafael
next prev parent reply other threads:[~2014-06-14 0:03 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-11 5:52 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
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 [this message]
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=87wqckqrxe.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=chiluk@canonical.com \
--cc=chris.j.arges@canonical.com \
--cc=davem@davemloft.net \
--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
all inboxes | Powered by JetHome®