Status of adaptive tickless patchset as of august 2012

[Frederic Weisbecker]

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.

- 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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/