Re: Status of adaptive tickless patchset as of august 2012

["Paul E. McKenney" <paulmck@linux.vnet.ibm.com>]

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