From: Lai Jiangshan <laijs@cn.fujitsu.com>
To: paulmck@linux.vnet.ibm.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 11:22:15 +0800 [thread overview]
Message-ID: <4917A8E7.8060801@cn.fujitsu.com> (raw)
In-Reply-To: <20081109005159.GM6917@linux.vnet.ibm.com>
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.
Thanx, Lai.
next prev parent reply other threads:[~2008-11-10 3:25 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 [this message]
2008-11-10 18:45 ` Paul E. McKenney
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=4917A8E7.8060801@cn.fujitsu.com \
--to=laijs@cn.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=paulmck@linux.vnet.ibm.com \
--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.