lkml.org 
[lkml]   [2012]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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.
>



\
 
 \ /
  Last update: 2012-08-18 17:21    [W:0.037 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site