Messages in this thread | | | Date | Mon, 30 Sep 2013 09:33:35 +0800 | From | Chen Gang <> | Subject | Re: [PATCH tip/core/rcu 08/11] rcu: Micro-optimize rcu_cpu_has_callbacks() |
| |
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 > > >
Thanks. -- Chen Gang
| |