netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Eric Dumazet <dada1@cosmosbay.com>
Cc: "David S. Miller" <davem@davemloft.net>,
	Linux Netdev List <netdev@vger.kernel.org>
Subject: Re: [PATCH] net: remove superfluous call to synchronize_net()
Date: Wed, 15 Apr 2009 14:54:54 -0700	[thread overview]
Message-ID: <20090415215454.GU6766@linux.vnet.ibm.com> (raw)
In-Reply-To: <49E5FF5E.50409@cosmosbay.com>

On Wed, Apr 15, 2009 at 05:38:06PM +0200, Eric Dumazet wrote:
> inet_register_protosw() is adding inet_protosw to inetsw[] with appropriate
> locking section and rcu variant. No need to call synchronize_net() to wait
> for a RCU grace period. Changes are immediatly visible to other cpus anyway.

I agree with the conclusion (that this change is safe), but not with
the reasoning process.  ;-)

The reason that this change is safe is that any inter-process
communication mechanism used to tell other CPUs that this protocol has
been registered must contain relevant memory barriers, otherwise, that
mechanism won't be reliable.

If an unreliable mechanism was to be used, the other CPU might not yet see
the protocol.  For example, if the caller did a simple non-atomic store
to a variable that the other CPU accessed with a simple non-atomic load,
then that other CPU could potentially see the inetsw[] without the new
protocol, given that inet_create() is lockless.  Unlikely, but possible.

But if a proper inter-process communication mechanism is used to inform
the other CPU, then the first CPU's memory operations will be seen.

So I suggest a comment to this effect.

> This saves about 13 ms on boot time on a HZ=1000 8 cpus machine ;)
> (4 calls to inet_register_protosw(), and about 3200 us per call)
> 
> But more seriously, we should audit all synchronize_{rcu|net}() calls
> to make sure we dont waste time and hide some bugs because of artificial
> delays.

Good point!

							Thanx, Paul

> Signed-off-by: Eric Dumazet <dada1@cosmosbay.com>
> 
> diff --git a/net/ipv4/af_inet.c b/net/ipv4/af_inet.c
> index 7f03373..1706896 100644
> --- a/net/ipv4/af_inet.c
> +++ b/net/ipv4/af_inet.c
> @@ -1003,8 +1003,6 @@ void inet_register_protosw(struct inet_protosw *p)
>  out:
>  	spin_unlock_bh(&inetsw_lock);
> 
> -	synchronize_net();
> -
>  	return;
> 
>  out_permanent:

  reply	other threads:[~2009-04-15 21:54 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-15 15:38 [PATCH] net: remove superfluous call to synchronize_net() Eric Dumazet
2009-04-15 21:54 ` Paul E. McKenney [this message]
2009-04-16  5:40   ` Eric Dumazet
2009-04-16 15:52     ` Paul E. McKenney
2009-04-16 16:03       ` Eric Dumazet
2009-04-16 18:02         ` Paul E. McKenney
2009-04-16 18:43           ` Eric Dumazet
2009-04-17 11:56     ` David Miller
2009-04-17 19:25       ` Paul E. McKenney

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=20090415215454.GU6766@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=dada1@cosmosbay.com \
    --cc=davem@davemloft.net \
    --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 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).