From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Alex Bligh <alex@alex.org.uk>
Cc: Eric Dumazet <eric.dumazet@gmail.com>, netdev@vger.kernel.org
Subject: Re: Scalability of interface creation and deletion
Date: Sun, 8 May 2011 07:47:49 -0700 [thread overview]
Message-ID: <20110508144749.GR2641@linux.vnet.ibm.com> (raw)
In-Reply-To: <C449131127D58077CB25C9D8@Ximines.local>
On Sun, May 08, 2011 at 03:27:07PM +0100, Alex Bligh wrote:
> Paul,
>
> >>Yes, really 20-49us and 50-99us, not ms. Raw data attached :-)
> >>
> >>I'm guessing there are circumstances where there is an early exit.
> >
> >Well, if you were onlining and offlining CPUs, then if there was only
> >one CPU online, this could happen.
>
> No, I wasn't doing that.
OK.
> > And there really is only one CPU
> >online during boot, so if your measurements included early boot time,
> >this could easily explain these very short timings.
>
> No, I waited a few minutes after boot for the system to stabilize, and
> all CPUs were definitely online.
>
> The patch to the kernel I am running is below.
OK, interesting...
My guess is that you need to be using ktime_get_ts(). Isn't ktime_get()
subject to various sorts of adjustment?
> >>There is nothing much going on these systems (idle, no other users,
> >>just normal system daemons).
> >
> >And normal system daemons might cause this, right?
>
> Yes. Everything is normal, except I did
> service udev stop
> unshare -n bash
> which together stop the system running interface scripts when
> interfaces are created (as upstart and upstart-udev-bridge are
> now integrated, you can't kill upstart, so you have to rely on
> unshare -n to stop the events being propagated). That's just
> to avoid measuring the time it takes to execute the scripts.
OK, so you really could be seeing grace periods started by these system
daemons.
Thanx, Paul
> --
> Alex Bligh
>
> diff --git a/kernel/rcutree.c b/kernel/rcutree.c
> index dd4aea8..e401018 100644
> --- a/kernel/rcutree.c
> +++ b/kernel/rcutree.c
> @@ -1518,6 +1518,7 @@ EXPORT_SYMBOL_GPL(call_rcu_bh);
> void synchronize_sched(void)
> {
> struct rcu_synchronize rcu;
> + ktime_t time_start = ktime_get();
>
> if (rcu_blocking_is_gp())
> return;
> @@ -1529,6 +1530,7 @@ void synchronize_sched(void)
> /* Wait for it. */
> wait_for_completion(&rcu.completion);
> destroy_rcu_head_on_stack(&rcu.head);
> + pr_err("synchronize_sched() in %lld us\n",
> ktime_us_delta(ktime_get(), time_start));
> }
> EXPORT_SYMBOL_GPL(synchronize_sched);
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 856b6ee..013f627 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -5164,7 +5164,9 @@ static void rollback_registered_many(struct
> list_head *head)
> dev = list_first_entry(head, struct net_device, unreg_list);
> call_netdevice_notifiers(NETDEV_UNREGISTER_BATCH, dev);
>
> + pr_err("begin rcu_barrier()\n");
> rcu_barrier();
> + pr_err("end rcu_barrier()\n");
>
> list_for_each_entry(dev, head, unreg_list)
> dev_put(dev);
> @@ -5915,8 +5917,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);
>
>
next prev parent reply other threads:[~2011-05-08 14:47 UTC|newest]
Thread overview: 53+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-07 11:08 Scalability of interface creation and deletion Alex Bligh
2011-05-07 12:22 ` Eric Dumazet
2011-05-07 15:26 ` Alex Bligh
2011-05-07 15:54 ` Eric Dumazet
2011-05-07 16:23 ` Ben Greear
2011-05-07 16:37 ` Eric Dumazet
2011-05-07 16:44 ` Ben Greear
2011-05-07 16:51 ` Eric Dumazet
2011-05-08 3:45 ` Ben Greear
2011-05-08 8:08 ` Alex Bligh
2011-05-09 21:46 ` Octavian Purdila
2011-05-07 16:26 ` Eric Dumazet
2011-05-07 18:24 ` Alex Bligh
2011-05-07 18:32 ` Eric Dumazet
2011-05-07 18:39 ` Eric Dumazet
2011-05-08 10:09 ` Alex Bligh
2011-05-07 18:42 ` Eric Dumazet
2011-05-07 18:50 ` Alex Bligh
2011-05-08 7:12 ` Eric Dumazet
2011-05-08 8:06 ` Alex Bligh
2011-05-08 9:35 ` Alex Bligh
2011-05-08 12:18 ` Alex Bligh
2011-05-08 12:50 ` Paul E. McKenney
2011-05-08 13:13 ` Alex Bligh
2011-05-08 13:44 ` Paul E. McKenney
2011-05-08 14:27 ` Alex Bligh
2011-05-08 14:47 ` Paul E. McKenney [this message]
2011-05-08 15:17 ` Alex Bligh
2011-05-08 15:48 ` Paul E. McKenney
2011-05-08 21:00 ` Eric Dumazet
2011-05-09 4:44 ` [PATCH] veth: use batched device unregister Eric Dumazet
2011-05-09 6:56 ` Michał Mirosław
2011-05-09 8:20 ` Eric Dumazet
2011-05-09 9:17 ` [PATCH net-next-2.6] net: use batched device unregister in veth and macvlan Eric Dumazet
2011-05-09 18:42 ` David Miller
2011-05-09 19:05 ` Eric Dumazet
2011-05-09 20:17 ` Eric Dumazet
2011-05-10 6:40 ` [PATCH net-2.6] vlan: fix GVRP at dismantle time Eric Dumazet
2011-05-10 19:23 ` David Miller
2011-05-09 7:45 ` [PATCH v2 net-next-2.6] veth: use batched device unregister Eric Dumazet
2011-05-09 9:22 ` Eric Dumazet
2011-05-09 5:37 ` Scalability of interface creation and deletion Alex Bligh
2011-05-09 6:37 ` Eric Dumazet
2011-05-09 7:11 ` Paul E. McKenney
2011-05-09 17:30 ` Jesse Gross
2011-05-08 12:44 ` Paul E. McKenney
2011-05-08 13:06 ` Alex Bligh
2011-05-08 13:14 ` Alex Bligh
2011-05-08 12:32 ` Paul E. McKenney
2011-05-07 18:51 ` Alex Bligh
2011-05-07 19:24 ` Eric Dumazet
2011-05-07 18:38 ` Alex Bligh
2011-05-07 18:44 ` Eric Dumazet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110508144749.GR2641@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=alex@alex.org.uk \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.