From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Octavian Purdila <opurdila@ixiacom.com>,
Benjamin LaHaise <bcrl@lhnet.ca>,
netdev@vger.kernel.org, Cosmin Ratiu <cratiu@ixiacom.com>
Subject: Re: [PATCH] net: allow netdev_wait_allrefs() to run faster
Date: Sat, 24 Oct 2009 07:46:10 -0700 [thread overview]
Message-ID: <20091024144610.GC6638@linux.vnet.ibm.com> (raw)
In-Reply-To: <4AE30E1B.5080008@gmail.com>
On Sat, Oct 24, 2009 at 04:24:27PM +0200, Eric Dumazet wrote:
> Paul E. McKenney a écrit :
> > On Sat, Oct 24, 2009 at 10:49:55AM +0200, Eric Dumazet wrote:
> >>
> >> On my dev machine, a synchronize_rcu() lasts between 2 an 12 ms
> >
> > That sounds like the right range, depending on what else is happening
> > on the machine at the time.
> >
> > The synchronize_rcu_expedited() primitive would run in the 10s-100s
> > of microseconds. It involves a pair of wakeups and a pair of context
> > switches on each CPU.
>
> Hmm... I'll make some experiments Monday and post results, but it seems very
> promising.
I should hasten to add that synchronize_rcu_expedited() goes fast for
TREE_RCU but not yet for TREE_PREEMPT_RCU (where it maps safely but
slowly to synchronize_rcu()).
> Do you think the "on_each_cpu(flush_backlog, dev, 1);"
> we perform right before calling netdev_wait_allrefs() could be changed
> somehow to speedup rcu callbacks ? Maybe we ould avoid sending IPI twice to
> cpus ?
This is an interesting possibility, and might fit in with some of the
changes that I am thinking about to reduce OS jitter for the heavy-duty
numerical-computing guys.
In the meantime, you could try doing the following from flush_backlog():
local_irq_save(flags);
rcu_check_callbacks(smp_processor_id(), 0);
local_irq_restore(flags);
This would emulate a much-faster HZ value, but only for RCU. This works
better in TREE_RCU than it does in TREE_PREEMPT_RCU at the moment (on my
todo list!). In older kernels, this should also work for CLASSIC_RCU.
Of course, in TINY_RCU, synchronize_rcu() is a no-op anyway. ;-)
And just to be clear, synchronize_rcu_expedited() currently just does
wakeups, not explicit IPIs.
Thanx, Paul
next prev parent reply other threads:[~2009-10-24 14:46 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-10-17 22:18 [PATCH/RFC] make unregister_netdev() delete more than 4 interfaces per second Benjamin LaHaise
2009-10-18 4:26 ` Eric Dumazet
2009-10-18 16:13 ` Benjamin LaHaise
2009-10-18 17:51 ` Eric Dumazet
2009-10-18 18:21 ` Benjamin LaHaise
2009-10-18 19:36 ` Eric Dumazet
2009-10-21 12:39 ` Octavian Purdila
2009-10-21 15:40 ` [PATCH] net: allow netdev_wait_allrefs() to run faster Eric Dumazet
2009-10-21 16:09 ` Eric Dumazet
2009-10-21 16:51 ` Benjamin LaHaise
2009-10-21 19:54 ` Eric Dumazet
2009-10-29 23:07 ` Eric W. Biederman
2009-10-29 23:38 ` Benjamin LaHaise
2009-10-30 1:45 ` Eric W. Biederman
2009-10-30 14:35 ` Benjamin LaHaise
2009-10-30 14:43 ` Eric Dumazet
2009-10-30 23:25 ` Eric W. Biederman
2009-10-30 23:53 ` Benjamin LaHaise
2009-10-31 0:37 ` Eric W. Biederman
2010-08-09 17:23 ` Ben Greear
2010-08-09 17:34 ` Benjamin LaHaise
2010-08-09 17:44 ` Ben Greear
2010-08-09 17:48 ` Benjamin LaHaise
2010-08-09 18:03 ` Ben Greear
2010-08-09 19:59 ` Eric W. Biederman
2010-08-09 21:03 ` Benjamin LaHaise
2010-08-09 21:17 ` Eric W. Biederman
2009-10-21 16:55 ` Octavian Purdila
2009-10-23 21:13 ` Paul E. McKenney
2009-10-24 4:35 ` Eric Dumazet
2009-10-24 5:49 ` Paul E. McKenney
2009-10-24 8:49 ` Eric Dumazet
2009-10-24 13:52 ` Paul E. McKenney
2009-10-24 14:24 ` Eric Dumazet
2009-10-24 14:46 ` Paul E. McKenney [this message]
2009-10-24 23:49 ` Octavian Purdila
2009-10-25 4:47 ` Paul E. McKenney
2009-10-25 8:35 ` Eric Dumazet
2009-10-25 15:19 ` Octavian Purdila
2009-10-25 19:28 ` Eric Dumazet
2009-10-24 20:22 ` Stephen Hemminger
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=20091024144610.GC6638@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=bcrl@lhnet.ca \
--cc=cratiu@ixiacom.com \
--cc=eric.dumazet@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=opurdila@ixiacom.com \
/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.