On 07/27/2015 09:49 AM, David Ahern wrote:
Hi Alex:I believe you did the recent overhaul to the fib implementation. I am seeing dramatically higher times to delete an interface with an ipv4 address in 4.2-rc3. perf-top points to update_suffix: PerfTop: 15834 irqs/sec kernel:97.3% exact: 0.0% [4000Hz cpu-clock], (all, 4 CPUs) ------------------------------------------------------------------------------------------- 74.69% [kernel] [k] update_suffix 2.38% [kernel] [k] fib_table_flush 2.20% [kernel] [k] fib6_walk_continue 2.03% [kernel] [k] fib6_ifdown 1.31% [kernel] [k] fib6_age I have a simple script to create and assign an ipv4 address to 10k dummy interfaces: l=0 for (( j = 1; j <= 40; j += 1)) do for (( k = 1 ; k <= 250 ; k += 1 )) do l=$((l + 1)) ip link add dev dummy${l} type dummy ip addr add 72.$j.$k.1/24 dev dummy${l} ifconfig dummy${l} up done done and a counter script to delete them all: k=$(ip link show | grep dummy | wc -l) for (( j = 1; j <= k; j += 1)) do ip link del dev dummy${j} done
Okay so looking over what this script does it looks like it really exposes the worst case scenerio for update_suffix. You have a monstrous tnode that is 15 bits ins size. That is roughly 32K entries, and unfortunately the suffix is 8 bits long with a position of 7.
The result is that for every removal the code is scanning 16K entries in order to relevel things after an entry is removed.
Let me try a couple of quick things and I should have a patch for you in the next couple of hours.
Thanks. - Alex -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
