[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1304783684.9216.2.camel@edumazet-laptop>
Date: Sat, 07 May 2011 17:54:44 +0200
From: Eric Dumazet <eric.dumazet@...il.com>
To: Alex Bligh <alex@...x.org.uk>
Cc: netdev@...r.kernel.org
Subject: Re: Scalability of interface creation and deletion
Le samedi 07 mai 2011 à 16:26 +0100, Alex Bligh a écrit :
> Well, I patched it (patch attached for what it's worth) and it made
> no difference in this case. I would suggest however that it might
> be the right think to do anyway.
>
As I said, this code should not be entered in normal situations.
You are not the first to suggest a change, but it wont help you at all.
> On the current 8 core box I am testing, I see 280ms per interface
> delete **even with only 10 interfaces**. I see 260ms with one
> interface. I know doing lots of rcu sync stuff can be slow, but
> 260ms to remove one veth pair sounds like more than rcu sync going
> on. It sounds like a sleep (though I may not have found the
> right one). I see no CPU load.
>
> Equally, with one interface (remember I'm doing this in unshare -n
> so there is only a loopback interface there), this bit surely
> can't be sysfs.
>
synchronize_rcu() calls are not consuming cpu, they just _wait_
rcu grace period.
I suggest you read Documentation/RCU files if you really want to :)
If you want to check how expensive it is, its quite easy:
add a trace in synchronize_net()
diff --git a/net/core/dev.c b/net/core/dev.c
index 856b6ee..70f3c46 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5915,8 +5915,10 @@ EXPORT_SYMBOL(free_netdev);
*/
void synchronize_net(void)
{
+ pr_err("begin synchronize_net()\n");
might_sleep();
synchronize_rcu();
+ pr_err("end synchronize_net()\n");
}
EXPORT_SYMBOL(synchronize_net);
--
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