Messages in this thread | | | Date | Sat, 18 Aug 2012 07:46:59 -0700 | From | "Paul E. McKenney" <> | Subject | Re: Status of adaptive tickless patchset as of august 2012 |
| |
On Sat, Aug 18, 2012 at 04:02:51PM +0200, Frederic Weisbecker wrote: > Hi, > > I started working on the adaptive nohz patchset by the end of 2010. Since then, I > iterated through one big branch: > > - Nohz tasks (https://lwn.net/Articles/420490/) > - Nohz cpusets (https://lwn.net/Articles/455044/) > - Nohz cpusets v2 (https://lwn.net/Articles/487599/) > - Nohz cpusets v3 (https://lwn.net/Articles/495422/) > > It quickly grew up to more than 40 patches. And still the full support > (ie: handle everything that the tick maintains, but without the tick) wasn't > yet finished. > > And the more I was progressing to get this full support, the more I had patches to > maintain, rebase, improve, etc... > > Some side effects went to increase: > > - I had deep reviews about the core overall design in the first iterations. Thanks > to that I made nice progresses. But as the patchset grew, I got less reviews about > overall design but more about details. And I can totally understand that. Huge pile > of patches certainly don't encourage reviews. > > - Lacking reviews on the overall design, I was feeling more and more uncomfortable about > whatever I was improving or whichever feature I was adding on top of the existing ones. > And I was indeed digging on some wrong direction for some parts. > > - I was spending too much time in out-of-tree maintainance while my goal is to get this > upstream. > > All in one, this big branch neither scaled in term of reviews nor development. > > So I decided, after Ingo proposed me to set a tree in -tip, to cut all of the things the > tick is handling and isolate each of these into single separate topics and handle them > individually or at least iteratively, trying to push the things upstream or in a staging > tree in -tip piecewise. As long as this is carried by concerned maintainers and I can get > their insights on a regular basis. And also as long as we can iterate to some central branch > because, even if we can cut out things into individual topics, there are significant interdependencies. > > I think this has been successfull so far: > > - The detection of illegal RCU read side critical sections under RCU extended quiescent > state is now upstream. This even helped finding lot of bugs upstream. > > - State of user as RCU extended quiescent state is currently pending in Paul's tree > in the rcu/idle branch. It's also in linux-next. This may likely go upstream or in > a staging branch in -tip for the next merge window.
Indeed, the current plan is to push it for 3.7. ;-)
Thanx, Paul
> - Some preparatory work to split nohz and idle logic in nohz API. It went upstream > on the last merge window. > > - Proposed something to handle nohz cputime accounting: https://lwn.net/Articles/501766/ > Got fundamental reviews that pointed me to rather reuse virtual based cputime accounting. > > - Consolidated/cleaned up virtual based cputime accounting (last version is > https://lkml.org/lkml/2012/8/17/326 and waits for inclusion in -tip or so.) > > - On top of that vtime consolidation and the RCU pending patches, propose > a generic virtual cputime accounting for archs that don't have CONFIG_VTIME_CPU_ACCOUNTING. > See http://comments.gmane.org/gmane.linux.kernel/1337690 > A tickless CPU can then account cputime with that. > > So the process seem to be in a better direction now. Summer holidays have naturally made it a > bit smoother and the rythm will probably stay that way until the end of ksummit/linuxcon/LPC. But > I have the feeling we are moving forward. > > No schedule plans, but once I get the above topics sorted out, I'll probably work on timekeeping > handling in adaptive tickless CPUs. And then the rest... > > I'll still keep maintaining the big branch in my tree. But this is now going to be rather a big draft or > laboratory, with regular rebases on what is merged upstream or in maintainers tree. It helps me to > keep a practical view of the big picture. > > Thanks. >
| |