Hide Forgot
Created attachment 1127483 [details] Sample code to test setns() performance with different namespaces Description of problem: As discussed yesterday facing a peculiar problem with setns () call. Trying to test the network namespace basic functionality and performance tests. The basic test is to create two network namespaces (nstest1, and nstest2) and enabled the loopback interfaces in them. Then the test program called setns () function (Re-associate thread with a namespace) to switch from namespace to nstest1, then from nstest1 to nstest2, from nstest2 to ntest1 etc. (round-robin). Version-Release number of selected component (if applicable): As part of the tests tried on kernel 3.6.57 and kernel 3.16.7, and ran the same setns() tests with only one CPU, and observed system call rates of several million calls per second. The results were incredibly different - for kernel 3.6.57 it was 0.22 micro second per setns() call vs. 2.1 milli second (10,000 times faster; for kernel 3.16.7 it was 0.16 micro second per setns() call vs. 31 milli second (200,000 times faster). 1. On kernel 3.6.57, the same test run on 1-CPU VM executed 100,000,000 setns () calls in 22 seconds (4,545,454 calls per second; 0.22 micro second per call). 2. On kernel 3.6.57, the same test run on 2-CPU or 4-CPU VM executed 10000 setns() calls in 21 seconds (476 calls per second; 2.1 milli second per call) How reproducible: easily and always reproducible Steps to Reproduce: Attached test program Details on the program below- test_netns.c – (attached). - Based on http://linux.die.net/man/2/setns Build: $ gcc -g -o test_netns test_netns.c Test setup: 1. Create network namespaces nstest1 and nstest2, and bring up loopback (lo) # ip netns add nstest1 # ip netns add nstest2 # ip netns exec nstest1 ip link set dev lo up # ip netns exec nstest2 ip link set dev lo up 2. Make sure that the namespaces are seen. # ip netns nstest1 nstest2 # ls /var/run/netns/ nstest1 nstest2 3. Get the PID of the current process. This PID is to be used in the test command. # echo $$ 24821 # 4. Run the test. Need to replace [PID] from the Step 3; replace [ITERS] with number of desired setns() calls. # ./test_netns /var/run/netns/nstest1 /var/run/netns/nstest2 /proc/[PID]/ns/net [ITERS] "/sbin/ip link" 4.A Example for running the test for 1000 iterations for PID=24821 for three namespaces: two namespaces and process's own: # ./test_netns /var/run/netns/nstest1 /var/run/netns/nstest2 /proc/24821/ns/net 1000 "/sbin/ip link" Actual results: Expected results: Additional info:
same test results in bare metal, vm and in docker container
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
Just wanted to be aware on the status of this bug and if any additional information is needed and the targeted release in which this may be probably fixed. Thanks.
Any update/progress on the Bug?
Hi, you have assigned the bug to openvswitch which doesn't seem to be related. Could you clarify or fix that?
Yes the Bug is against the Linux Kernel. I think I assigned the Bug incorrectly, can we please assign this to Linux Kernel group ? Thanks.
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There are a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 24 kernel bugs. Fedora 25 has now been rebased to 4.10.9-100.fc24. Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel. If you have moved on to Fedora 26, and are still experiencing this issue, please change the version to Fedora 26. If you experience different issues, please open a new bug report for those.
*********** MASS BUG UPDATE ************** This bug is being closed with INSUFFICIENT_DATA as there has not been a response in 2 weeks. If you are still experiencing this issue, please reopen and attach the relevant data from the latest kernel you are running and any data that might have been requested previously.