LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Johannes Weiner <hannes-kernel@saeurebad.de>
Cc: ego@in.ibm.com, linux-kernel@vger.kernel.org,
	linux-rt-users@vger.kernel.org, Ingo Molnar <mingo@elte.hu>,
	Steven Rostedt <rostedt@goodmis.org>,
	Dipankar Sarma <dipankar@in.ibm.com>, Ted Tso <tytso@us.ibm.com>,
	dvhltc@us.ibm.com, Oleg Nesterov <oleg@tv-sign.ru>,
	Andrew Morton <akpm@linux-foundation.org>,
	bunk@kernel.org, Josh Triplett <josh@freedesktop.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>
Subject: Re: [RFC PATCH 2/6] Preempt-RCU: Reorganize RCU code into rcuclassic.c and rcupdate.c
Date: Fri, 14 Dec 2007 08:12:14 -0800	[thread overview]
Message-ID: <20071214161214.GB14177@linux.vnet.ibm.com> (raw)
In-Reply-To: <x7fxy572jh.fsf@saeurebad.de>

On Fri, Dec 14, 2007 at 03:51:14PM +0100, Johannes Weiner wrote:
> Hi,
> 
> Gautham R Shenoy <ego@in.ibm.com> writes:
> 
> > diff --git a/kernel/rcuclassic.c b/kernel/rcuclassic.c
> > new file mode 100644
> > index 0000000..11c16aa
> > --- /dev/null
> > +++ b/kernel/rcuclassic.c
> > +/**
> > + * call_rcu - Queue an RCU callback for invocation after a grace period.
> > + * @head: structure to be used for queueing the RCU updates.
> > + * @func: actual update function to be invoked after the grace period
> > + *
> > + * The update function will be invoked some time after a full grace
> > + * period elapses, in other words after all currently executing RCU
> > + * read-side critical sections have completed.  RCU read-side critical
> > + * sections are delimited by rcu_read_lock() and rcu_read_unlock(),
> > + * and may be nested.
> > + */
> > +void call_rcu(struct rcu_head *head,
> > +				void (*func)(struct rcu_head *rcu))
> > +{
> > +	unsigned long flags;
> > +	struct rcu_data *rdp;
> > +
> > +	head->func = func;
> > +	head->next = NULL;
> > +	local_irq_save(flags);
> > +	rdp = &__get_cpu_var(rcu_data);
> > +	*rdp->nxttail = head;
> > +	rdp->nxttail = &head->next;
> > +	if (unlikely(++rdp->qlen > qhimark)) {
> > +		rdp->blimit = INT_MAX;
> > +		force_quiescent_state(rdp, &rcu_ctrlblk);
> > +	}
> > +	local_irq_restore(flags);
> > +}
> > +EXPORT_SYMBOL_GPL(call_rcu);
> > +
> > +/**
> > + * call_rcu_bh - Queue an RCU for invocation after a quicker grace period.
> > + * @head: structure to be used for queueing the RCU updates.
> > + * @func: actual update function to be invoked after the grace period
> > + *
> > + * The update function will be invoked some time after a full grace
> > + * period elapses, in other words after all currently executing RCU
> > + * read-side critical sections have completed. call_rcu_bh() assumes
> > + * that the read-side critical sections end on completion of a softirq
> > + * handler. This means that read-side critical sections in process
> > + * context must not be interrupted by softirqs. This interface is to be
> > + * used when most of the read-side critical sections are in softirq context.
> > + * RCU read-side critical sections are delimited by rcu_read_lock() and
> > + * rcu_read_unlock(), * if in interrupt context or rcu_read_lock_bh()
> > + * and rcu_read_unlock_bh(), if in process context. These may be nested.
> > + */
> > +void call_rcu_bh(struct rcu_head *head,
> > +				void (*func)(struct rcu_head *rcu))
> > +{
> > +	unsigned long flags;
> > +	struct rcu_data *rdp;
> > +
> > +	head->func = func;
> > +	head->next = NULL;
> > +	local_irq_save(flags);
> > +	rdp = &__get_cpu_var(rcu_bh_data);
> > +	*rdp->nxttail = head;
> > +	rdp->nxttail = &head->next;
> > +
> > +	if (unlikely(++rdp->qlen > qhimark)) {
> > +		rdp->blimit = INT_MAX;
> > +		force_quiescent_state(rdp, &rcu_bh_ctrlblk);
> > +	}
> > +
> > +	local_irq_restore(flags);
> > +}
> > +EXPORT_SYMBOL_GPL(call_rcu_bh);
> 
> Those two functions are identical beside the difference of `rcu_data'
> <-> `rcu_bh_data' and `rcu_ctrlblk' <-> `rcu_bh_ctrlblk'.
> 
> Is there a way to collapse the code into one helper function or would
> that effect performance too much?

This code is performance critical, but on the other hand, perhaps gcc
has gotten smarter in the years since this was written.  (This patch is
just moving this code from one file to another, rather than writing it
from scratch.)  Would current gcc implementations be able to do the
inlining required?

							Thanx, Paul

  reply	other threads:[~2007-12-14 16:13 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-12-13 17:03 [RFC PATCH 0/6] RCU: Preemptible-RCU Gautham R Shenoy
2007-12-13 17:14 ` [RFC PATCH 1/6] Preempt-RCU: Use softirq instead of tasklets for RCU Gautham R Shenoy
2007-12-13 17:15 ` [RFC PATCH 2/6] Preempt-RCU: Reorganize RCU code into rcuclassic.c and rcupdate.c Gautham R Shenoy
2007-12-14 14:51   ` Johannes Weiner
2007-12-14 16:12     ` Paul E. McKenney [this message]
2007-12-13 17:16 ` [RFC PATCH 3/6] Preempt-RCU: Fix rcu_barrier for preemptive environment Gautham R Shenoy
2007-12-13 17:16 ` [RFC PATCH 4/6] Preempt-RCU: Implementation Gautham R Shenoy
2008-02-29  4:34   ` Roman Zippel
2008-02-29  4:53     ` Paul E. McKenney
2008-02-29 12:38       ` Roman Zippel
2008-02-29 13:55         ` Steven Rostedt
2008-03-01 19:39         ` Paul E. McKenney
2008-03-01 21:07           ` Steven Rostedt
2008-03-02  3:09             ` Roman Zippel
2008-03-02  3:06           ` Roman Zippel
2008-03-03 18:55             ` Paul E. McKenney
2008-03-04 20:22               ` [PATCH] move PREEMPT_RCU config option back under PREEMPT Paul E. McKenney
2008-03-04 20:55                 ` Steven Rostedt
2008-03-05  0:58                   ` Paul E. McKenney
2008-03-05  2:06                     ` Roman Zippel
2008-03-05 19:00                       ` Paul E. McKenney
2008-03-04 20:49               ` [RFC PATCH 4/6] Preempt-RCU: Implementation Roman Zippel
2008-02-29 13:53     ` Steven Rostedt
2008-02-29 14:31       ` Roman Zippel
2007-12-13 17:17 ` [RFC PATCH 5/6] Preempt-RCU: CPU Hotplug handling Gautham R Shenoy
2007-12-13 17:18 ` [RFC PATCH 6/6] Preempt-RCU: Update RCU Documentation Gautham R Shenoy
2007-12-13 20:42   ` Ingo Molnar
2007-12-13 21:06     ` Gautham R Shenoy
2007-12-13 17:36 ` [RFC PATCH 0/6] RCU: Preemptible-RCU Steven Rostedt
2007-12-13 20:42   ` Ingo Molnar
2007-12-13 20:56     ` Steven Rostedt
2007-12-13 21:09   ` Gautham R Shenoy
2007-12-13 20:38 ` Ingo Molnar
2007-12-13 23:41   ` 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=20071214161214.GB14177@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=akpm@linux-foundation.org \
    --cc=bunk@kernel.org \
    --cc=dipankar@in.ibm.com \
    --cc=dvhltc@us.ibm.com \
    --cc=ego@in.ibm.com \
    --cc=hannes-kernel@saeurebad.de \
    --cc=josh@freedesktop.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rt-users@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=oleg@tv-sign.ru \
    --cc=rostedt@goodmis.org \
    --cc=tglx@linutronix.de \
    --cc=tytso@us.ibm.com \
    --subject='Re: [RFC PATCH 2/6] Preempt-RCU: Reorganize RCU code into rcuclassic.c and rcupdate.c' \
    /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

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).