From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Ingo Molnar <mingo@elte.hu>, Dipankar Sarma <dipankar@in.ibm.com>,
Gautham Shenoy <ego@in.ibm.com>,
Dhaval Giani <dhaval@linux.vnet.ibm.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH 2/2] rcu classic: new algorithm for callbacks-processing(v2)
Date: Wed, 6 Aug 2008 20:19:20 -0700 [thread overview]
Message-ID: <20080807031920.GB6910@linux.vnet.ibm.com> (raw)
In-Reply-To: <48994DDA.70205@cn.fujitsu.com>
On Wed, Aug 06, 2008 at 03:08:10PM +0800, Lai Jiangshan wrote:
> Paul E. McKenney wrote:
> [...]
> >
> > Tell me more about percpu_ptr().
>
> Sorry about this. percpu_ptr is used for dynamic allocation percpu pointer.
Yep, that I knew.
> It seems that we cannot get a pointer from a static declare percpu data
> which can be used as a dynamic allocation percpu data's pointer.
Sad but true... Ran into this with SRCU a couple of years back. :-/
> >
> [...]
> >
> > I have a somewhat different goal here. I want to simplify the memory
> > ordering design without giving up too much performance -- the current
> > state in mainline is much too fragile, in my opinion, especially given
> > that the grace-period code paths are not fastpaths.
> >
> > Next step -- hierarchical grace-period detection to handle the 4096-CPU
> > machines that I was being buttonholed about at OLS...
> >
> > Would you be interested in applying your multi-tailed list change to
> > preemptable RCU?
> >
> It's not necessary. Actually I like one tail per list which is good for
> readability.
>
> But in my patch, the most work is combining lists, not
> moving a list to next list, so i use multi-tailed simplify this works
> and others(etc: "if (rdp->nxtlist)" will be changed to be a more
> complex and less readability statement if i use one-tail-per-list)
>
> These not means multi-tailed is good thing.
It does indeed depend on the details of the implementation.
Thanx, Paul
next prev parent reply other threads:[~2008-08-07 3:19 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-06 9:23 [RFC][PATCH 2/2] rcu classic: new algorithm for callbacks-processing(v2) Lai Jiangshan
2008-07-18 14:09 ` Ingo Molnar
2008-08-01 21:10 ` Paul E. McKenney
[not found] ` <20080721100433.GC8384@linux.vnet.ibm.com>
2008-08-01 21:10 ` Paul E. McKenney
2008-08-03 8:01 ` Lai Jiangshan
2008-08-04 22:54 ` Paul E. McKenney
2008-08-06 7:08 ` Lai Jiangshan
2008-08-07 3:19 ` Paul E. McKenney [this message]
[not found] ` <20080725165454.GA7147@linux.vnet.ibm.com>
2008-08-01 21:11 ` 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=20080807031920.GB6910@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=a.p.zijlstra@chello.nl \
--cc=dhaval@linux.vnet.ibm.com \
--cc=dipankar@in.ibm.com \
--cc=ego@in.ibm.com \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
/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.