Re: [RFC PATCH 4/5] RCU: Add TASK_RCU_OFFSET

[Lai Jiangshan]

On 04/08/2011 12:26 AM, Paul E. McKenney wrote:
> On Thu, Apr 07, 2011 at 08:47:37AM -0700, Paul E. McKenney wrote:
>> On Thu, Apr 07, 2011 at 01:49:51PM +0800, Lai Jiangshan wrote:
>>> On 04/07/2011 08:30 AM, Paul E. McKenney wrote:
>>>> On Wed, Apr 06, 2011 at 02:27:39PM -0700, H. Peter Anvin wrote:
>>>>> On 04/06/2011 02:06 PM, Peter Zijlstra wrote:
>>>>>> On Wed, 2011-04-06 at 13:13 -0700, Paul E. McKenney wrote:
>>>>>>> And the following patch builds correctly for defconfig x86 builds,
>>>>>>> while allowing rcupdate.h to see the sched.h definitions as needed
>>>>>>> to inline rcu_read_lock() and rcu_read_unlock().
>>>>>>>
>>>>>> Looks like an entirely reasonable patch to me ;-)
>>>>>>
>>>>>
>>>>> Quite... a lot better than the original proposal!
>>>>
>>>> Glad you both like it!
>>>>
>>>> When I do an allyesconfig build, I do get errors during the "CHECK"
>>>> phase, when it is putting things into the usr/include in the build tree.
>>>> I believe that this is because I am exposing different header files to
>>>> the library-export scripts.  The following patch silences some of them,
>>>> but I am really out of my depth here.
>>>>
>>>> Sam, Jan, Michal, help?
>>>>
>>>> 							Thanx, Paul
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>
>>> Easy to split rcupdate.h, hard to resolve the dependence problem.
>>>
>>> You can apply the next additional patch when you test:
>>
>> I am sure that you are quite correct.  ;-)
>>
>> I am moving _rcu_read_lock() and _rcu_read_unlock() into
>> include/linux/rcutree.h and include/linux/rcutiny.h, and I am sure that
>> more pain will ensue.
>>
>> One thing I don't understand...  How does is it helping to group the
>> task_struct RCU-related fields into a structure?  Is that generating
>> better code on your platform due to smaller offsets or something?

You don't like task_rcu_struct patch? I think it can make code clearer,
and it can also check the code even when CONFIG_PREEMPT_RCU=n.

For rcu_read_[un]lock(), it generates the same code, no better, no worse.

It is just a cleanup patch, it is helpless for making rcu_read_[un]lock() inline,
if you don't like it, I will give up it.

>>
>> Also, does your patchset address the CHECK warnings?
> 
> I take it back...  I applied the following patch on top of my earlier
> one, and a defconfig x86 build completed without error.  (Though I have
> not tested the results of the build.)
> 
> One possible difference -- I did this work on top of a recent Linus
> git commit (b2a8b4b81966) rather than on top of my -rcu tree.  Also,
> I have not yet tried an allyesconfig build, which will no doubt locate
> some more problems.
> 
> 							Thanx, Paul
> 

when defconfig or allyesconfig, CONFIG_PREEMPT=n and CONFIG_TREE_PREEMPT_RCU=n
when you make them "y":

In file included from include/linux/rcupdate.h:764:0,
                 from include/linux/tracepoint.h:19,
                 from include/linux/module.h:18,
                 from include/linux/crypto.h:21,
                 from arch/x86/kernel/asm-offsets.c:8:
include/linux/rcutree.h:50:20: error: static declaration of â__rcu_read_lockâ follows non-static declaration
include/linux/rcupdate.h:76:13: note: previous declaration of â__rcu_read_lockâ was here
include/linux/rcutree.h:63:20: error: static declaration of â__rcu_read_unlockâ follows non-static declaration
include/linux/rcupdate.h:77:13: note: previous declaration of â__rcu_read_unlockâ was here
make[1]: *** [arch/x86/kernel/asm-offsets.s] Error 1
make: *** [prepare0] Error 2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/