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

[Chen Gang]

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. ;-)


Thanks.

> 							Thanx, Paul
> 
>> On 09/25/2013 09:29 AM, Paul E. McKenney wrote:
>>> From: "Paul E. McKenney" <paulmck@xxxxxxxxxxxxxxxxxx>
>>>
>>> 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@xxxxxxxxxxx>
>>> Signed-off-by: Paul E. McKenney <paulmck@xxxxxxxxxxxxxxxxxx>
>>> ---
>>>  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
--
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/