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

Reply via email to