From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Stephen Hemminger <shemminger@vyatta.com>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: [PATCH net-2.6.26] fib_trie: RCU optimizations
Date: Fri, 21 Mar 2008 09:01:03 -0700 [thread overview]
Message-ID: <20080321160103.GG9618@linux.vnet.ibm.com> (raw)
In-Reply-To: <20080321075521.49347370@extreme>
On Fri, Mar 21, 2008 at 07:55:21AM -0700, Stephen Hemminger wrote:
> Small performance improvements.
>
> Eliminate unneeded barrier on deletion. The first pointer to update
> the head of the list is ordered by the second call to rcu_assign_pointer.
> See hlist_add_after_rcu or comparision.
>
> Move rcu_derference to the loop check (like hlist_for_each_rcu), and
> add a prefetch.
Acked-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Justification below.
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> --- a/net/ipv4/route.c 2008-03-19 08:45:32.000000000 -0700
> +++ b/net/ipv4/route.c 2008-03-19 08:54:57.000000000 -0700
> @@ -977,8 +977,8 @@ restart:
> * must be visible to another weakly ordered CPU before
> * the insertion at the start of the hash chain.
> */
> - rcu_assign_pointer(rth->u.dst.rt_next,
> - rt_hash_table[hash].chain);
> + rth->u.dst.rt_next = rt_hash_table[hash].chain;
> +
This is OK because it is finalizing a deletion. If this were instead
an insertion, this would of course be grossly illegal and dangerous.
> /*
> * Since lookup is lockfree, the update writes
> * must be ordered for consistency on SMP.
> @@ -2076,8 +2076,9 @@ int ip_route_input(struct sk_buff *skb,
> hash = rt_hash(daddr, saddr, iif);
>
> rcu_read_lock();
> - for (rth = rcu_dereference(rt_hash_table[hash].chain); rth;
> - rth = rcu_dereference(rth->u.dst.rt_next)) {
> + for (rth = rt_hash_table[hash].chain; rcu_dereference(rth);
> + rth = rth->u.dst.rt_next) {
> + prefetch(rth->u.dst.rt_next);
> if (rth->fl.fl4_dst == daddr &&
> rth->fl.fl4_src == saddr &&
> rth->fl.iif == iif &&
Works, though I would guess that increasingly aggressive compiler
optimization will eventually force us to change the list.h macros
to look like what you had to begin with... Sigh!!!
next parent reply other threads:[~2008-03-21 16:01 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20080321075521.49347370@extreme>
2008-03-21 16:01 ` Paul E. McKenney [this message]
2008-03-21 17:25 ` [PATCH net-2.6.26] fib_trie: RCU optimizations Eric Dumazet
2008-03-21 17:31 ` Stephen Hemminger
2008-03-21 17:44 ` Eric Dumazet
2008-03-21 22:49 ` David Miller
2008-03-21 22:50 ` David Miller
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=20080321160103.GG9618@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=davem@davemloft.net \
--cc=netdev@vger.kernel.org \
--cc=shemminger@vyatta.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).