From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: linux-kernel@vger.kernel.org, mingo@elte.hu,
laijs@cn.fujitsu.com, dipankar@in.ibm.com,
akpm@linux-foundation.org, mathieu.desnoyers@polymtl.ca,
josh@joshtriplett.org, niv@us.ibm.com, tglx@linutronix.de,
peterz@infradead.org, rostedt@goodmis.org,
Valdis.Kletnieks@vt.edu, dhowells@redhat.com,
edumazet@google.com, darren@dvhart.com, sbw@mit.edu,
patches@linaro.org, joe.korty@ccur.com,
"Paul E. McKenney" <paul.mckenney@linaro.org>
Subject: Re: [PATCH tip/core/rcu 1/2] rcu: Add callback-free CPUs
Date: Fri, 2 Nov 2012 11:41:32 -0700 [thread overview]
Message-ID: <20121102184132.GB3027@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAFTL4hwv6xTiMYMe7ZpYk1bkDVJiwk-DQAm1tRXDFD2OyO_W=A@mail.gmail.com>
On Wed, Oct 31, 2012 at 03:10:04PM +0100, Frederic Weisbecker wrote:
> 2012/10/31 Paul E. McKenney <paulmck@linux.vnet.ibm.com>:
> > +/*
> > + * Per-rcu_data kthread, but only for no-CBs CPUs. Each kthread invokes
> > + * callbacks queued by the corresponding no-CBs CPU.
> > + */
> > +static int rcu_nocb_kthread(void *arg)
> > +{
> > + int c, cl;
> > + struct rcu_head *list;
> > + struct rcu_head *next;
> > + struct rcu_head **tail;
> > + struct rcu_data *rdp = arg;
> > +
> > + /* Each pass through this loop invokes one batch of callbacks */
> > + for (;;) {
> > + /* If not polling, wait for next batch of callbacks. */
> > + if (!rcu_nocb_poll)
> > + wait_event(rdp->nocb_wq, rdp->nocb_head);
> > + list = ACCESS_ONCE(rdp->nocb_head);
> > + if (!list) {
> > + schedule_timeout_interruptible(1);
> > + continue;
> > + }
> > +
> > + /*
> > + * Extract queued callbacks, update counts, and wait
> > + * for a grace period to elapse.
> > + */
> > + ACCESS_ONCE(rdp->nocb_head) = NULL;
> > + tail = xchg(&rdp->nocb_tail, &rdp->nocb_head);
> > + c = atomic_long_xchg(&rdp->nocb_q_count, 0);
> > + cl = atomic_long_xchg(&rdp->nocb_q_count_lazy, 0);
> > + ACCESS_ONCE(rdp->nocb_p_count) += c;
> > + ACCESS_ONCE(rdp->nocb_p_count_lazy) += cl;
> > + wait_rcu_gp(rdp->rsp->call_remote);
> > +
> > + /* Each pass through the following loop invokes a callback. */
> > + trace_rcu_batch_start(rdp->rsp->name, cl, c, -1);
> > + c = cl = 0;
> > + while (list) {
> > + next = list->next;
> > + /* Wait for enqueuing to complete, if needed. */
> > + while (next == NULL && &list->next != tail) {
> > + schedule_timeout_interruptible(1);
> > + next = list->next;
> > + }
> > + debug_rcu_head_unqueue(list);
> > + local_bh_disable();
> > + if (__rcu_reclaim(rdp->rsp->name, list))
> > + cl++;
> > + c++;
> > + local_bh_enable();
> > + list = next;
> > + }
> > + trace_rcu_batch_end(rdp->rsp->name, c, !!list, 0, 0, 1);
> > + ACCESS_ONCE(rdp->nocb_p_count) -= c;
> > + ACCESS_ONCE(rdp->nocb_p_count_lazy) -= cl;
> > + rdp->n_cbs_invoked += c;
> > + }
> > + return 0;
> > +}
> > +
> > +/* Initialize per-rcu_data variables for no-CBs CPUs. */
> > +static void __init rcu_boot_init_nocb_percpu_data(struct rcu_data *rdp)
> > +{
> > + rdp->nocb_tail = &rdp->nocb_head;
> > + init_waitqueue_head(&rdp->nocb_wq);
> > +}
> > +
> > +/* Create a kthread for each RCU flavor for each no-CBs CPU. */
> > +static void __init rcu_spawn_nocb_kthreads(struct rcu_state *rsp)
> > +{
> > + int cpu;
> > + struct rcu_data *rdp;
> > + struct task_struct *t;
> > +
> > + if (rcu_nocb_mask == NULL)
> > + return;
> > + for_each_cpu(cpu, rcu_nocb_mask) {
> > + rdp = per_cpu_ptr(rsp->rda, cpu);
> > + t = kthread_run(rcu_nocb_kthread, rdp, "rcuo%d", cpu);
>
> Sorry, I think I left my brain in the middle of the diff. But there is
> something I'm misunderstanding I think. Here you're creating an
> rcu_nocb_kthread per nocb cpu. Looking at the code of
> rcu_nocb_kthread(), it seems to execute the callbacks with
> __rcu_reclaim().
True, executing within the context of the kthread, which might be
executing on any CPU.
> So, in the end, no callbacks CPU execute their callbacks. Isn't it the
> opposite than what is expected? (again, just referring to my
> misunderstanding).
The no-callbacks CPU would execute its own callbacks only if the
corresponding kthread happened to be executing on that CPU.
If you wanted a given CPU to be completely free of callbacks,
you would instead constrain the corresponding kthread to run
elsewhere.
Thanx, Paul
> Thanks.
>
> > + BUG_ON(IS_ERR(t));
> > + ACCESS_ONCE(rdp->nocb_kthread) = t;
> > + }
> > +}
>
next prev parent reply other threads:[~2012-11-02 18:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-31 3:45 [PATCH tip/core/rcu 0/2] v2 Add callback-free CPUs Paul E. McKenney
2012-10-31 3:46 ` [PATCH tip/core/rcu 1/2] rcu: " Paul E. McKenney
2012-10-31 3:46 ` [PATCH tip/core/rcu 2/2] rcu: Separate accounting of callbacks from " Paul E. McKenney
2012-10-31 14:10 ` [PATCH tip/core/rcu 1/2] rcu: Add " Frederic Weisbecker
2012-11-02 18:41 ` Paul E. McKenney [this message]
2012-11-02 21:21 ` Frederic Weisbecker
2012-10-31 7:25 ` [PATCH tip/core/rcu 0/2] v2 " Peter Zijlstra
2012-10-31 7:44 ` 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=20121102184132.GB3027@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=Valdis.Kletnieks@vt.edu \
--cc=akpm@linux-foundation.org \
--cc=darren@dvhart.com \
--cc=dhowells@redhat.com \
--cc=dipankar@in.ibm.com \
--cc=edumazet@google.com \
--cc=fweisbec@gmail.com \
--cc=joe.korty@ccur.com \
--cc=josh@joshtriplett.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@polymtl.ca \
--cc=mingo@elte.hu \
--cc=niv@us.ibm.com \
--cc=patches@linaro.org \
--cc=paul.mckenney@linaro.org \
--cc=peterz@infradead.org \
--cc=rostedt@goodmis.org \
--cc=sbw@mit.edu \
--cc=tglx@linutronix.de \
/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