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.
>
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" <paul...@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.c...@asianux.com>
>>>>> Signed-off-by: Paul E. McKenney <paul...@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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
