| 2013-09-17 17:23:27 |
Chris J Arges |
bug |
|
|
added bug |
| 2013-09-17 17:23:27 |
Chris J Arges |
attachment added |
|
graph.png https://bugs.launchpad.net/bugs/1226726/+attachment/3825673/+files/graph.png |
|
| 2013-09-17 17:25:06 |
Chris J Arges |
attachment added |
|
test_ns.sh https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1226726/+attachment/3825692/+files/test_ns.sh |
|
| 2013-09-17 17:25:37 |
Chris J Arges |
nominated for series |
|
Ubuntu Precise |
|
| 2013-09-17 17:25:37 |
Chris J Arges |
bug task added |
|
linux (Ubuntu Precise) |
|
| 2013-09-17 17:25:37 |
Chris J Arges |
nominated for series |
|
Ubuntu Quantal |
|
| 2013-09-17 17:25:37 |
Chris J Arges |
bug task added |
|
linux (Ubuntu Quantal) |
|
| 2013-09-17 17:25:37 |
Chris J Arges |
nominated for series |
|
Ubuntu Saucy |
|
| 2013-09-17 17:25:37 |
Chris J Arges |
bug task added |
|
linux (Ubuntu Saucy) |
|
| 2013-09-17 17:25:37 |
Chris J Arges |
nominated for series |
|
Ubuntu Raring |
|
| 2013-09-17 17:25:37 |
Chris J Arges |
bug task added |
|
linux (Ubuntu Raring) |
|
| 2013-09-17 17:25:45 |
Chris J Arges |
linux (Ubuntu Raring): assignee |
|
Chris J Arges (arges) |
|
| 2013-09-17 17:25:47 |
Chris J Arges |
linux (Ubuntu Quantal): assignee |
|
Chris J Arges (arges) |
|
| 2013-09-17 17:25:49 |
Chris J Arges |
linux (Ubuntu Precise): assignee |
|
Chris J Arges (arges) |
|
| 2013-09-17 17:25:52 |
Chris J Arges |
linux (Ubuntu Precise): importance |
Undecided |
Medium |
|
| 2013-09-17 17:25:55 |
Chris J Arges |
linux (Ubuntu Quantal): importance |
Undecided |
Medium |
|
| 2013-09-17 17:25:57 |
Chris J Arges |
linux (Ubuntu Raring): importance |
Undecided |
Medium |
|
| 2013-09-17 17:25:59 |
Chris J Arges |
linux (Ubuntu Saucy): importance |
Medium |
Undecided |
|
| 2013-09-17 17:26:01 |
Chris J Arges |
linux (Ubuntu Saucy): assignee |
Chris J Arges (arges) |
|
|
| 2013-09-17 17:26:03 |
Chris J Arges |
linux (Ubuntu Saucy): status |
New |
Fix Released |
|
| 2013-09-17 17:26:12 |
Chris J Arges |
linux (Ubuntu Precise): status |
New |
In Progress |
|
| 2013-09-17 17:26:13 |
Chris J Arges |
linux (Ubuntu Quantal): status |
New |
In Progress |
|
| 2013-09-17 17:26:15 |
Chris J Arges |
linux (Ubuntu Raring): status |
New |
In Progress |
|
| 2013-09-17 17:46:54 |
Chris J Arges |
linux (Ubuntu Precise): importance |
Medium |
High |
|
| 2013-09-17 17:46:56 |
Chris J Arges |
linux (Ubuntu Raring): importance |
Medium |
High |
|
| 2013-09-17 17:47:00 |
Chris J Arges |
linux (Ubuntu Quantal): importance |
Medium |
High |
|
| 2013-09-30 18:17:47 |
Chris J Arges |
description |
Whenever one enters a network namespace via "ip netns exec foobar somecommand" there is a mount done of the appropriate device on /sys since "somecommand" needs to see namespace specific versions of /sys directories. When the ip process exits these mounts need to be torn down, and that requires a global write lock for vfsmount_lock (this is a single writer multiple reader lock). This has serious performance implications when the number of name spaces increase.
The commit 84d17192 addresses this issue, and it is clear by running the attached testcase that it fixes performance issues when dealing with large numbers of namespaces. I've included a graph with the differences in performance between this fix and its parent commit to show the the improve in performance. The x-axis represents the number of namespaces and the y-axis is execution time in ms. After applying the patch the performance delays are not exponentially increasing.
This affects 3.2/3.5/3.8 series kernels, as it was fixed in 3.10. |
SRU Justification:
Impact: When creating thousands of network namespaces the delay in executing commands increases exponentially in kernels before 84d17192.
Fix: In 84d17192 in the upstream kernel, locking code in fs/namespace.c is greatly improved resulting in much better performance when the number namespaces increase.
Testcase: Below, test_ns.sh can be run and a graph can be compared between the existing version and the patched version.
Additional Information: Because this is a change in the vfs layer, I ran the xfstests and compared before and after results of this patch. The patch did not create any additional failures in the generic xfstests.
--
Whenever one enters a network namespace via "ip netns exec foobar somecommand" there is a mount done of the appropriate device on /sys since "somecommand" needs to see namespace specific versions of /sys directories. When the ip process exits these mounts need to be torn down, and that requires a global write lock for vfsmount_lock (this is a single writer multiple reader lock). This has serious performance implications when the number of name spaces increase.
The commit 84d17192 addresses this issue, and it is clear by running the attached testcase that it fixes performance issues when dealing with large numbers of namespaces. I've included a graph with the differences in performance between this fix and its parent commit to show the the improve in performance. The x-axis represents the number of namespaces and the y-axis is execution time in ms. After applying the patch the performance delays are not exponentially increasing.
This affects 3.2/3.5/3.8 series kernels, as it was fixed in 3.10. |
|
| 2013-10-03 20:51:54 |
Chris J Arges |
description |
SRU Justification:
Impact: When creating thousands of network namespaces the delay in executing commands increases exponentially in kernels before 84d17192.
Fix: In 84d17192 in the upstream kernel, locking code in fs/namespace.c is greatly improved resulting in much better performance when the number namespaces increase.
Testcase: Below, test_ns.sh can be run and a graph can be compared between the existing version and the patched version.
Additional Information: Because this is a change in the vfs layer, I ran the xfstests and compared before and after results of this patch. The patch did not create any additional failures in the generic xfstests.
--
Whenever one enters a network namespace via "ip netns exec foobar somecommand" there is a mount done of the appropriate device on /sys since "somecommand" needs to see namespace specific versions of /sys directories. When the ip process exits these mounts need to be torn down, and that requires a global write lock for vfsmount_lock (this is a single writer multiple reader lock). This has serious performance implications when the number of name spaces increase.
The commit 84d17192 addresses this issue, and it is clear by running the attached testcase that it fixes performance issues when dealing with large numbers of namespaces. I've included a graph with the differences in performance between this fix and its parent commit to show the the improve in performance. The x-axis represents the number of namespaces and the y-axis is execution time in ms. After applying the patch the performance delays are not exponentially increasing.
This affects 3.2/3.5/3.8 series kernels, as it was fixed in 3.10. |
SRU Justification:
Impact: When creating thousands of network namespaces the delay in executing commands increases exponentially in kernels before 84d17192.
Fix: In 84d17192 in the upstream kernel, locking code in fs/namespace.c is greatly improved resulting in much better performance when the number namespaces increase.
Testcase: Below, test_ns.sh can be run and a graph can be compared between the existing version and the patched version.
Additional Information: Because this is a change in the vfs layer, I ran the xfstests and compared before and after results of this patch. The patch did not create any additional failures in the generic xfstests.
The quantal and raring solutions differ but are both based on the 84d17192
patch. The quantal solution does a backport of this patch instead of clean
cherry-picks because of the amount of deps required to just use cherry-picks.
The raring solution was able to be done with two clean cherry-picks and that's
why that solution was chosen.
--
Whenever one enters a network namespace via "ip netns exec foobar somecommand" there is a mount done of the appropriate device on /sys since "somecommand" needs to see namespace specific versions of /sys directories. When the ip process exits these mounts need to be torn down, and that requires a global write lock for vfsmount_lock (this is a single writer multiple reader lock). This has serious performance implications when the number of name spaces increase.
The commit 84d17192 addresses this issue, and it is clear by running the attached testcase that it fixes performance issues when dealing with large numbers of namespaces. I've included a graph with the differences in performance between this fix and its parent commit to show the the improve in performance. The x-axis represents the number of namespaces and the y-axis is execution time in ms. After applying the patch the performance delays are not exponentially increasing.
This affects 3.2/3.5/3.8 series kernels, as it was fixed in 3.10. |
|
| 2013-10-04 16:03:44 |
Andy Whitcroft |
linux (Ubuntu Quantal): status |
In Progress |
Fix Committed |
|
| 2013-10-04 16:03:46 |
Andy Whitcroft |
linux (Ubuntu Raring): status |
In Progress |
Fix Committed |
|
| 2013-10-04 16:12:55 |
Chris J Arges |
linux (Ubuntu Precise): status |
In Progress |
Won't Fix |
|
| 2013-10-04 16:12:58 |
Chris J Arges |
linux (Ubuntu Precise): assignee |
Chris J Arges (arges) |
|
|
| 2013-10-08 20:28:14 |
Mark Russell |
bug |
|
|
added subscriber Mark Russell |
| 2013-10-28 14:36:29 |
Brad Figg |
tags |
bot-stop-nagging |
bot-stop-nagging verification-needed-quantal |
|
| 2013-10-28 14:37:20 |
Brad Figg |
tags |
bot-stop-nagging verification-needed-quantal |
bot-stop-nagging verification-needed-quantal verification-needed-raring |
|
| 2013-11-01 20:39:12 |
Jonathan Davies |
tags |
bot-stop-nagging verification-needed-quantal verification-needed-raring |
bot-stop-nagging verification-done-quantal verification-needed-raring |
|
| 2013-11-01 20:53:41 |
Jonathan Davies |
tags |
bot-stop-nagging verification-done-quantal verification-needed-raring |
bot-stop-nagging verification-done-quantal verification-done-raring |
|
| 2013-11-08 00:35:21 |
Launchpad Janitor |
linux (Ubuntu Quantal): status |
Fix Committed |
Fix Released |
|
| 2013-11-08 00:35:21 |
Launchpad Janitor |
cve linked |
|
2013-1819 |
|
| 2013-11-08 00:35:21 |
Launchpad Janitor |
cve linked |
|
2013-2888 |
|
| 2013-11-08 00:35:21 |
Launchpad Janitor |
cve linked |
|
2013-2889 |
|
| 2013-11-08 00:35:21 |
Launchpad Janitor |
cve linked |
|
2013-2892 |
|
| 2013-11-08 00:35:21 |
Launchpad Janitor |
cve linked |
|
2013-2893 |
|
| 2013-11-08 00:35:21 |
Launchpad Janitor |
cve linked |
|
2013-2895 |
|
| 2013-11-08 00:35:21 |
Launchpad Janitor |
cve linked |
|
2013-2896 |
|
| 2013-11-08 00:35:21 |
Launchpad Janitor |
cve linked |
|
2013-2897 |
|
| 2013-11-08 00:35:21 |
Launchpad Janitor |
cve linked |
|
2013-2899 |
|
| 2013-11-08 00:36:40 |
Launchpad Janitor |
linux (Ubuntu Raring): status |
Fix Committed |
Fix Released |
|
| 2013-11-08 00:36:40 |
Launchpad Janitor |
cve linked |
|
2013-2147 |
|
| 2013-11-08 00:36:40 |
Launchpad Janitor |
cve linked |
|
2013-2894 |
|
| 2013-11-08 00:36:40 |
Launchpad Janitor |
cve linked |
|
2013-4343 |
|
