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.
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
>
--
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/
