Re: [PATCH tip/core/rcu 08/11] rcu: Micro-optimize rcu_cpu_has_callbacks()

[Chen Gang <gang.chen@asianux.com>]

On 09/27/2013 10:29 AM, Chen Gang wrote:
> On 09/27/2013 02:33 AM, Paul E. McKenney wrote:
>> On Thu, Sep 26, 2013 at 10:57:39AM +0800, Chen Gang wrote:
>>> On 09/26/2013 04:16 AM, Paul E. McKenney wrote:
>>>> On Wed, Sep 25, 2013 at 10:55:30AM +0800, Chen Gang wrote:
>>>>>
>>>>> Thank you for your whole work, firstly  :-).
>>>>>
>>>>> And your suggestion about testing (in our discussion) is also valuable
>>>>> to me.
>>>>>
>>>>> I need start LTP in q4. After referenced your suggestion, my first step
>>>>> for using/learning LTP is not mainly for finding kernel issues, but for
>>>>> testing kernel (to improve my kernel testing efficiency).
>>>>>
>>>>> When I want to find issues by reading code, I will consider about LTP
>>>>> too (I will try to find issues which can be tested by LTP).
>>>>
>>>> Doing more testing will be good!  You will probably need more tests
>>>> than just LTP, but you must of course start somewhere.
>>>
>>> Give more testing is good, but also mean more time resources cost. If
>>> spend the 'cost', also need get additional 'contributions' (not only
>>> prove an issue), or the 'efficiency' can not be 'acceptable'.
>>>
>>> When "I need more tests than just LTP", firstly I need perform this
>>> test, and then, also try to send "test case" to LTP (I guess, these
>>> kinds of mails are welcomed by LTP).
>>>
>>> And LTP is also a way to find kernel issues, although I will not mainly
>>> depend on it now (but maybe in future), it is better to familiar with it
>>> step by step.
>>>
>>> LTP (Linux Test Project) is one of main kernel mad user at downstream.
>>> Tool chain (GCC/Binutils) is one of kernel main mad tools at upstream.
>>> If we face to the whole kernel, suggest to use them. ;-)
>>
>> Yep, starting with just LTP is OK.  But if by this time next year you
>> really should be using more than just LTP.
>>

What I have done is trying to fully use other members contributions, not trying to instead of them.


And the reason why I want/try to 'open' my 'ideas' to public:

  get more suggestions, and completions from other members.

  share my ideas, it can let other members provide more contributions (e.g. I am glad, if find other members also try 'allmodconfig' on all architectures).

  If some members replicate me, I will save my current time resources and devote them to another things (which also based on other members contributions).


In my opinion:

  "Open and Share" are both important and urgent to everyone, although it may not be noticed directly. Like "Air and Water" which God have blessed to everyone.


Thanks.

> 
> Hmm... LTP is "Linux Test Project", if I make some test cases which is
> useful for the issue which I find, I guess, these test cases are also
> welcomed by LTP.
> 
> Except testing, "I really should be using more than just LTP" (just
> like you said).
> 
> e.g.
> 
>   Tool Chain: just I am trying.
> 
>     According to my current time resources, within this year, I can not finish allmodconfig on all architectures. :-(
>     I am just solving one gcc issue, it seems it is not quite difficult, but at least now, I have no time on it. :-(
> 
>   Documents: just I am trying.
> 
>     I am trying to discuss API definition comments, but it seems I am not well done. :-(
>     I am also trying some of trivial patches, neither seems what I have done is well enough. :-(
>     Communicating and discussing related issues with other members. Only this, it seems not quite bad. :-)
> 
>   LTP:  I will try in q4 2013.
> 
>     In fact, when I first comes to our Public Kernel, I already use LTP (and disccus an nfs issue by LTP test), which is still suspending. :-(
>     In my original plan (not declare to outside), I want to start LTP in q3 2013, but fails (because of no time resources). :-(
> 
> 
>   Bugzilla: plan to try in next year.
> 
>     I also want to solve some issues which comes from Bugzilla (especially for some issues which no one wants to try).
>     but according to my current action result and time resources, I can not dare to declare it to outside in next year. :-(
> 
>   And I still have some company internal things to do (which may be urgent, sometimes), it will consume my 20-40% time resources. :-(
> 
> 
> So, please understand with each other: every members' time resource is
> expensive, we have to take care of it. and also, I thank all members
> who can spend their time resources on my mail and disccus with me.
> 
> 
> Thanks.
> 
>> 							Thanx, Paul
>>
>>>>> On 09/25/2013 09:29 AM, Paul E. McKenney wrote:
>>>>>> From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
>>>>>>
>>>>>> The for_each_rcu_flavor() loop unconditionally scans all flavors, even
>>>>>> when the first flavor might have some non-lazy callbacks.  Once the
>>>>>> loop has seen a non-lazy callback, further passes through the loop
>>>>>> cannot change the state.  This is not a huge problem, given that there
>>>>>> can be at most three RCU flavors (RCU-bh, RCU-preempt, and RCU-sched),
>>>>>> but this code is on the path to idle, so speeding it up even a small
>>>>>> amount would have some benefit.
>>>>>>
>>>>>> This commit therefore does two things:
>>>>>>
>>>>>> 1.	Rearranges the order of the list of RCU flavors in order to
>>>>>> 	place the most active flavor first in the list.  The most active
>>>>>> 	RCU flavor is RCU-preempt, or, if there is no RCU-preempt,
>>>>>> 	RCU-sched.
>>>>>>
>>>>>> 2.	Reworks the for_each_rcu_flavor() to exit early when the first
>>>>>> 	non-lazy callback is seen, or, in the case where the caller
>>>>>> 	does not care about non-lazy callbacks (RCU_FAST_NO_HZ=n),
>>>>>> 	when the first callback is seen.
>>>>>>
>>>>>> Reported-by: Chen Gang <gang.chen@asianux.com>
>>>>>> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>>>>>> ---
>>>>>>  kernel/rcutree.c | 11 +++++++----
>>>>>>  1 file changed, 7 insertions(+), 4 deletions(-)
>>>>>>
>>>>>> diff --git a/kernel/rcutree.c b/kernel/rcutree.c
>>>>>> index e6f2e8f..49464ad 100644
>>>>>> --- a/kernel/rcutree.c
>>>>>> +++ b/kernel/rcutree.c
>>>>>> @@ -2727,10 +2727,13 @@ static int rcu_cpu_has_callbacks(int cpu, bool *all_lazy)
>>>>>>  
>>>>>>  	for_each_rcu_flavor(rsp) {
>>>>>>  		rdp = per_cpu_ptr(rsp->rda, cpu);
>>>>>> -		if (rdp->qlen != rdp->qlen_lazy)
>>>>>> +		if (!rdp->nxtlist)
>>>>>> +			continue;
>>>>>> +		hc = true;
>>>>>> +		if (rdp->qlen != rdp->qlen_lazy || !all_lazy) {
>>>>>>  			al = false;
>>>>>> -		if (rdp->nxtlist)
>>>>>> -			hc = true;
>>>>>> +			break;
>>>>>> +		}
>>>>>>  	}
>>>>>>  	if (all_lazy)
>>>>>>  		*all_lazy = al;
>>>>>> @@ -3297,8 +3300,8 @@ void __init rcu_init(void)
>>>>>>  
>>>>>>  	rcu_bootup_announce();
>>>>>>  	rcu_init_geometry();
>>>>>> -	rcu_init_one(&rcu_sched_state, &rcu_sched_data);
>>>>>>  	rcu_init_one(&rcu_bh_state, &rcu_bh_data);
>>>>>> +	rcu_init_one(&rcu_sched_state, &rcu_sched_data);
>>>>>>  	__rcu_init_preempt();
>>>>>>  	open_softirq(RCU_SOFTIRQ, rcu_process_callbacks);
>>>>>>  
>>>>>>
>>>>>
>>>>>
>>>>> -- 
>>>>> Chen Gang
>>>>>
>>>>> -- 
>>>>> Chen Gang
>>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> -- 
>>> Chen Gang
>>>
>>
>>
>>
> 
> 


-- 
Chen Gang