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

From: Chen Gang
Date: Sun Sep 29 2013 - 21:34:53 EST

On 09/30/2013 04:23 AM, Paul E. McKenney wrote:
> On Sun, Sep 29, 2013 at 12:24:52PM +0800, Chen Gang wrote:
>> 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.

Firstly, thank you very much for your details reply.

> In a general sense, of course.
> In many specific cases, effective sharing can require quite a bit of
> preparation. For but one example, in Dipankar's and my case, it took
> about two years of work (mostly Dipankar's work) to get the initial
> implementation of RCU accepted into the Linux kernel.
> In your case, you can invest an average of three days per accepted
> patch if you are to achieve your goal of ten patches accepted per month
> (if I remember correctly). Of course, not every patch will be accepted,
> which reduces your per-patch time. For example, if 50% of your patches
> are accepted, you can invest an average of about 1.5 days per patch.
> Of course, investing in learning about test frameworks or specific
> kernel subsystems further reduces your time available per patch.
> But if you don't invest in your learning, you will be limited in what
> you can effectively contribute. This might be OK, for all I know.
> After all, in the 15 million lines of Linux kernel code, there is
> probably a very large number of point-problems waiting to be fixed.
> But suppose that you run out of easily found point problems? Or that
> you want to do something more wide-ranging than fixes for point problems?
> What can you do?
> Here are a few options. If you think more about it, I am sure that you
> can come up with others.
> 1. Put the ten-patches-per-month quota aside for a month (or two or
> three or whatever is required and appropriate). Spend this time
> studying a given kernel subsystem or a given test framework.
> (Which kernel subsystem? The best candidates would be those
> having bugs but no active maintainer, but which you have the
> hardware needed to adequately test.)
> 2. Add a review and/or test component to your monthly quota, so
> that a given patch could be substituted for by some number of
> Reviewed-by or Tested-by flags. Of course, this gives your
> a chicken-and-egg problem because you cannot adequately review
> or test without some understanding of the subsystem in question.
> (At least not efficiently enough to get enough Tested-by or
> Reviewed-by flags.)
> 3. Set aside a fixed amount of time each week (or each month) to
> learn. This time needs to be a contiguous block of at least
> four hours. If you focus your learning appropriately, you might
> be able to contribute more deeply to whatever you learned about
> over time.
> For whatever it is worth, just staring at code is for most people
> an inefficient way to learn. Exercising the code using tools
> like ftrace or userspace scaffolding can help speed up the
> learning.

At least for me, what you said is valuable.

In fact, I am just trying in this way for Tool Chain (GCC/Binutils),
and use Linux Kernel as the test object of Tool Chain. ;-)

> 4. Your idea here...

'Ways' depends on your goal.

For Tool Chain and LTP, I only want to use them for kernel, so I need
familiar with their features details which related with Linux Kernel,
(in fact, GCC is not easy for me, too).

But for Linux Kernel, I want to face the whole kernel (it is my main
goal), so I start from Interface: kernel's upstream (e.g. Tool Chain),
kernel's downstream (e.g. LTP), and Reading Code/Docs.

So what I have done to Linux kernel, is just only starting, it can be
followed with many many next steps.

> Your current approach seems to be to submit patches and hope that the
> maintainer takes it upon himself or herself to teach you. Unfortunately,
> as you might have noticed, a given maintainer might not have the time
> or energy to take on full responsibility for your education.

In my opinion, teaching and educating are not quite efficient: I am not
graduated from University (no bachelor's degree, not computer science
major, either), although I come from China Zhe Jiang University.

When I send a patch to the related maintainer (or integrator), I don't
intend to let them 'teach' me (it is not quite efficient), I only want
to work together which can improve the whole efficiency.

e.g. if the maintainers already know about it, we don't need wast time again.
e.g. if no related maintainer, I should try and let integrator check and provide him/her suggestions for what I have done.

> Thanx, Paul

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
Please read the FAQ at