netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Eric Dumazet <eric.dumazet@gmail.com>
Cc: Hans Schillstrom <hans.schillstrom@ericsson.com>,
	Daniel Lezcano <daniel.lezcano@free.fr>,
	"lvs-devel@vger.kernel.org" <lvs-devel@vger.kernel.org>,
	"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
	"netfilter-devel@vger.kernel.org"
	<netfilter-devel@vger.kernel.org>,
	"horms@verge.net.au" <horms@verge.net.au>,
	"ja@ssi.bg" <ja@ssi.bg>,
	"wensong@linux-vs.org" <wensong@linux-vs.org>
Subject: Re: [RFC PATCH 1/9] ipvs network name space aware
Date: Thu, 21 Oct 2010 08:16:13 -0700	[thread overview]
Message-ID: <20101021151613.GB2363@linux.vnet.ibm.com> (raw)
In-Reply-To: <1287651504.6871.44.camel@edumazet-laptop>

On Thu, Oct 21, 2010 at 10:58:24AM +0200, Eric Dumazet wrote:
> 
> > You said that there were a lot of "stepi" commands to get through
> > rcu_read_lock() on x86_64.  This is quite surprising, especially if you
> > built with CONFIG_RCU_TREE.  Even if you built with CONFIG_PREEMPT_RCU_TREE,
> > you should only see something like the following from rcu_read_lock():
> > 
> > 000000b7 <__rcu_read_lock>:
> >       b7:	55                   	push   %ebp
> >       b8:	64 a1 00 00 00 00    	mov    %fs:0x0,%eax
> >       be:	ff 80 80 01 00 00    	incl   0x180(%eax)
> >       c4:	89 e5                	mov    %esp,%ebp
> >       c6:	5d                   	pop    %ebp
> >       c7:	c3                   	ret    
> > 
> > Unless you have some sort of debugging options turned on.  Or unless
> > six instructions counts for "quite many" stepi commands.  ;-)
> 
> Paul, this should be inlined, dont you think ?

Indeed it should!!!  It is out-of-line due to header-file issues.
Lai Jiangshan proposed a change to kbuild to allow it to be inlined as
part of his ring-RCU patch, and I have asked him to submit a version
of that for Tree and Tiny preemptible RCU.  This is the usual trick of
having the build system compile the data structure and emit offsets,
which are then used in the main kernel build.  (Yes, I did something
similar in DYNIX/ptx, but never managed to work up the courage to attempt
the equivalent in Linux's kbuild, so props to Lai!)

> Also, I dont understand why we use ACCESS_ONCE() in rcu_read_lock()
> 
> ACCESS_ONCE(current->rcu_read_lock_nesting)++;
> 
> Apparently, some compilers are a bit noisy here.
> 
> mov    0x1b0(%rdx),%eax
> inc    %eax
> mov    %eax,0x1b0(%rdx)
> 
> instead of :
> 
> incl   0x1b0(%rax)
> 
> So if the ACCESS_ONCE() is needed, we might add a comment, because it's
> not obvious ;)

Here is what it looks like in my -rcu tree:

void __rcu_read_lock(void)
{
	current->rcu_read_lock_nesting++;
	barrier();  /* needed if we ever invoke rcu_read_lock in rcutree.c */
}

So yes, I finally did convince myself that the ACCESS_ONCE was not
needed.  ;-)

This is not yet in mainline, but Ingo sent the series containing this
commit (80dcf60e) to Linus earlier today, so there is hope!

							Thanx, Paul

  reply	other threads:[~2010-10-21 15:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-08 11:16 [RFC PATCH 1/9] ipvs network name space aware Hans Schillstrom
2010-10-18  8:59 ` Daniel Lezcano
2010-10-18  9:54   ` Hans Schillstrom
2010-10-18 11:37     ` Daniel Lezcano
2010-10-18 13:23       ` Hans Schillstrom
2010-10-18 14:26         ` Daniel Lezcano
2010-10-19 18:44         ` Paul E. McKenney
2010-10-20  8:25           ` Hans Schillstrom
2010-10-20 16:02             ` Paul E. McKenney
2010-10-21  7:45               ` Hans Schillstrom
2010-10-21  8:01                 ` Eric Dumazet
2010-10-21 15:18                   ` Paul E. McKenney
2010-10-21  8:58               ` Eric Dumazet
2010-10-21 15:16                 ` Paul E. McKenney [this message]
2010-10-21 15:24                   ` 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=20101021151613.GB2363@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=daniel.lezcano@free.fr \
    --cc=eric.dumazet@gmail.com \
    --cc=hans.schillstrom@ericsson.com \
    --cc=horms@verge.net.au \
    --cc=ja@ssi.bg \
    --cc=lvs-devel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=wensong@linux-vs.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).