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

[Lai Jiangshan <laijs@cn.fujitsu.com>]

On 04/08/2011 01:13 PM, Paul E. McKenney wrote:
> On Fri, Apr 08, 2011 at 09:26:16AM +0800, Lai Jiangshan wrote:
>> 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.
> 
> I don't know that I feel strongly either way about it.  It was necessary
> with the integer-offset approach, but optional now.
> 
>>>> 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
> 
> Yep.  I need to move the rcu_read_lock() APIs to follow the inclusion
> of rcutree.h and rcutiny.h.  Also add include of sched.h to rcutiny.h.
> The code movement does bloat the patch a bit.  But rcu_assign_pointer()
> must precede the inclusion of rcutree.h and rcutiny.h, so it is not
> possible to simply move the inclusions.  See below.
> 
> 							Thanx, Paul
> 

sched.h still contains rcupdate.h after applied this patch.
See my [PATCH 2/4] for more info.


# make lib/is_single_threaded.o
  CHK     include/linux/version.h
  CHK     include/generated/utsrelease.h
  CALL    scripts/checksyscalls.sh
  CC      lib/is_single_threaded.o
In file included from include/linux/rcupdate.h:639:0,
                 from include/linux/rculist.h:10,
                 from include/linux/sched.h:82,
                 from lib/is_single_threaded.c:13:
include/linux/rcutree.h: In function ‘__rcu_read_lock’:
include/linux/rcutree.h:52:15: error: dereferencing pointer to incomplete type
In file included from include/linux/rcupdate.h:639:0,
                 from include/linux/rculist.h:10,
                 from include/linux/sched.h:82,
                 from lib/is_single_threaded.c:13:
include/linux/rcutree.h: In function ‘__rcu_read_unlock’:
include/linux/rcutree.h:68:5: error: dereferencing pointer to incomplete type
include/linux/rcutree.h:70:7: error: dereferencing pointer to incomplete type
include/linux/rcutree.h:71:46: error: dereferencing pointer to incomplete type
include/linux/rcutree.h:71:78: error: dereferencing pointer to incomplete type
include/linux/rcutree.h:71:6: warning: type defaults to ‘int’ in type name
make[1]: *** [lib/is_single_threaded.o] Error 1
make: *** [lib/is_single_threaded.o] Error 2