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