[lkml]   [2012]   [Aug]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectStatus of adaptive tickless patchset as of august 2012

    I started working on the adaptive nohz patchset by the end of 2010. Since then, I
    iterated through one big branch:

    - Nohz tasks (
    - Nohz cpusets (
    - Nohz cpusets v2 (
    - Nohz cpusets v3 (

    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

    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:
    Got fundamental reviews that pointed me to rather reuse virtual based cputime accounting.

    - Consolidated/cleaned up virtual based cputime accounting (last version is 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.
    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.


     \ /
      Last update: 2012-08-18 16:21    [W:0.027 / U:48.588 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site