There is 3 upstream patches[1] "Under Review", that has been created to mitigate this specific situation. The test (with these patches) so far has been proven to provide better performance.
The patches consist on allocating the percpu counters in page-sized batch chunks. [1] - Patches : http://patchwork.ozlabs.org/patch/697259/ http://patchwork.ozlabs.org/patch/697260/ http://patchwork.ozlabs.org/patch/697261/ - Eric ** Summary changed: - netfilter regression introducing a performance slowdown in binary ip/ip6tables + netfilter regression introducing a performance slowdown in binary arp/iptables/ip6tables ** Summary changed: - netfilter regression introducing a performance slowdown in binary arp/iptables/ip6tables + netfilter regression introducing a performance slowdown in binary arp/ip/ip6tables -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux in Ubuntu. https://bugs.launchpad.net/bugs/1640786 Title: netfilter regression introducing a performance slowdown in binary arp/ip/ip6tables Status in linux package in Ubuntu: Confirmed Bug description: Explanation : It has been brought to my attention that Ubuntu kernel 4.4 has a severe netfilter regression affecting the performance of "/sbin/iptables" command, especially when adding large number of policies. My source have documented everything here[2]. I was able to reproduce the situation on my side, and a kernel bisect identified the same offending commit[1] as my source found for this bug. Running the commit right before the offending one have proven to have expected performance : # commit [71ae0dff] <== Offending commit real 0m33.314s user 0m1.520s sys 0m26.192s # commit [d7b59742] <== Right before offending commit real 0m5.952s user 0m0.124s sys 0m0.220s Reproducer : $ iptables -F $ echo 3 > /proc/sys/vm/drop_caches $ time (./list-addrs 3000 | xargs -n1 iptables -A FORWARD -j ACCEPT -s) "list-addrs" script can be found here[3] Note : * "iptables-restore" doesn't suffer of that netfilter regression, and I'm also aware that "iptables-restore" is the favourite approach since it is way more efficient than iptables that is executed over and over, once for each policy one want to set, but since "/sbin/iptables" takes vastly longer to perform with that commit, I think this need to be address anyway. * I also tried with the latest and greatest iptables upstream code, and got the same result. Reference : [1] - https://github.com/torvalds/linux/commit/71ae0dff02d756e4d2ca710b79f2ff5390029a5f [2] - https://gist.github.com/williammartin/b75e3faf5964648299e4d985413e6c0c [3] - https://gist.github.com/williammartin/b75e3faf5964648299e4d985413e6c0c#file-list-addrs To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1640786/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp
