From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Lai Jiangshan <laijs@cn.fujitsu.com>
Cc: Ingo Molnar <mingo@elte.hu>,
Peter Zijlstra <peterz@infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] rcupdate: move synchronize_sched() back to rcupdate.c V2
Date: Mon, 10 Nov 2008 10:45:20 -0800 [thread overview]
Message-ID: <20081110184520.GC6685@linux.vnet.ibm.com> (raw)
In-Reply-To: <4917A8E7.8060801@cn.fujitsu.com>
On Mon, Nov 10, 2008 at 11:22:15AM +0800, Lai Jiangshan wrote:
> Paul E. McKenney wrote:
> > On Thu, Nov 06, 2008 at 02:47:44PM +0800, Lai Jiangshan wrote:
> >> this fix remove ugly macro, and increase readability for rcupdate codes
> >>
> >> changed from v1:
> >> use HAVE_SPECIAL_RCU_BH/SCHED instead of define duplicate version of
> >> synchronize_sched().
> >
> > Hello, Jiangshan!
> >
> > I very much like getting rid of the ugly macro. I of course like the
> > kernel-doc fixes. ;-)
> >
> > I am not yet convinced of the HAVE_SPECIAL_RCU_BH and
> > HAVE_SPECIAL_RCU_SCHED pieces. It is not clear to me that this approach
> > is simpler than the current approach of simply providing the appropriate
> > definitions for the symbols in the implementation-specific rcuxxx.h
> > file.
> >
> > Am I missing something?
> >
> > Thanx, Paul
> >
>
> I think:
>
> RCU_BH is not required, we can used RCU instead. so HAVE_SPECIAL_RCU_BH
> will help for implementation which has not RCU_BH.
>
> HAVE_SPECIAL_RCU_SCHED is a little different, RCU and RCU_SCHED are both
> required for the kernel. But I think, in an implementation,
> if rcu_read_lock_sched() implies rcu_read_lock(), we may not need implement
> RCU_SCHED too(sometimes we may implement RCU_SCHED for performance).
> so HAVE_SPECIAL_RCU_SCHED will help.
If I understand correctly, this is the "old way":
------------------------------------------------------------------------
rcupdate.h:
#define rcu_read_lock_bh() __rcu_read_lock_bh()
#define rcu_read_unlock_bh() __rcu_read_unlock_bh()
rcupreempt.h:
#define __rcu_read_lock_bh() { rcu_read_lock(); local_bh_disable(); }
#define __rcu_read_unlock_bh() { local_bh_enable(); rcu_read_unlock(); }
------------------------------------------------------------------------
And then this is the "new way":
------------------------------------------------------------------------
rcupdate.h:
#ifdef HAVE_SPECIAL_RCU_BH
#define rcu_read_lock_bh() __rcu_read_lock_bh()
#define rcu_read_unlock_bh() __rcu_read_unlock_bh()
#else
#define __rcu_read_lock_bh() { rcu_read_lock(); local_bh_disable(); }
#define __rcu_read_unlock_bh() { local_bh_enable(); rcu_read_unlock(); }
#endif /* HAVE_SPECIAL_RCU_BH */
rcupreempt.h:
#define HAVE_SPECIAL_RCU_BH
------------------------------------------------------------------------
If we had ten different RCU implementations, then the "new way" would save
a little bit of code. But the "old way" is a bit easier to figure out.
So I am in favor of getting rid of the ugly macro, and also in favor
of fixing the kerneldoc, but opposed to the HAVE_SPECIAL_RCU_BH and
HAVE_SPECIAL_RCU_SCHED changes.
Or am I missing something?
Thanx, Paul
next prev parent reply other threads:[~2008-11-10 18:45 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-06 6:47 [PATCH] rcupdate: move synchronize_sched() back to rcupdate.c V2 Lai Jiangshan
2008-11-06 6:57 ` Ingo Molnar
2008-11-09 0:51 ` Paul E. McKenney
2008-11-10 3:22 ` Lai Jiangshan
2008-11-10 18:45 ` Paul E. McKenney [this message]
2008-11-11 0:55 ` Lai Jiangshan
2008-11-11 1:03 ` Paul E. McKenney
2008-11-13 2:48 ` Lai Jiangshan
2008-11-13 17:31 ` Paul E. McKenney
2008-11-14 1:03 ` Lai Jiangshan
2008-11-14 2:11 ` Paul E. McKenney
2008-11-14 7:39 ` Lai Jiangshan
2008-11-14 19:25 ` Jonathan Corbet
2008-11-15 20:39 ` Paul E. McKenney
2008-11-17 12:57 ` Lai Jiangshan
2008-11-17 21:28 ` Jonathan Corbet
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=20081110184520.GC6685@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=akpm@linux-foundation.org \
--cc=laijs@cn.fujitsu.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=peterz@infradead.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 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.