[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <270382A9E068495F7E8A14CC@Ximines.local>
Date: Sat, 07 May 2011 19:51:01 +0100
From: Alex Bligh <alex@...x.org.uk>
To: Eric Dumazet <eric.dumazet@...il.com>
cc: netdev@...r.kernel.org, Alex Bligh <alex@...x.org.uk>
Subject: Re: Scalability of interface creation and deletion
--On 7 May 2011 20:32:54 +0200 Eric Dumazet <eric.dumazet@...il.com> wrote:
> Well, there is also one rcu_barrier() call that is expensive.
> (It was changed from one synchronize_rcu() to one rcu_barrier() lately
> in commit ef885afb , in 2.6.36 kernel)
I think you are saying it may be waiting in rcu_barrier(). I'll
instrument that later plus synchronize_sched().
> http://git2.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commi
> tdiff;h=ef885afbf8a37689afc1d9d545e2f3e7a8276c17
OK, so in head, which I am using, rollback_registered_many which
previously had 2 calls to synchronize_net(), now has one, followed
by a call to rc_barrier() at the bottom.
> netdev_wait_allrefs() waits that all references to a device vanishes.
>
> It currently uses a _very_ pessimistic 250 ms delay between each probe.
> Some users reported that no more than 4 devices can be dismantled per
> second, this is a pretty serious problem for some setups.
Right, that's what I patched before (see patch attached to
message from earlier today) to do an exponential backoff (see
previous entry), i.e. do a 5ms sleep, then a 10ms, then a 20ms, but
never more than 250ms. It made no difference.
> time to remove 50 ipip tunnels on a UP machine :
>
> before patch : real 11.910s
> after patch : real 1.250s
Sadly I don't see that improvement!
--
Alex Bligh
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists