lkml.org 
[lkml]   [2006]   [Mar]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: cpu scheduler merge plans

    * Andrew Morton <akpm@osdl.org> wrote:

    > So it's that time again. We need to decide which of the queued sched
    > patches should be merged into 2.6.17.
    >
    > I have:
    >
    > sched-fix-task-interactivity-calculation.patch
    > small-schedule-microoptimization.patch
    > #
    > sched-implement-smpnice.patch
    > sched-smpnice-apply-review-suggestions.patch
    > sched-smpnice-fix-average-load-per-run-queue-calculations.patch
    > sched-store-weighted-load-on-up.patch
    > sched-add-discrete-weighted-cpu-load-function.patch
    > sched-add-above-background-load-function.patch
    >
    > # Suresh had problems
    > # con:
    > sched-cleanup_task_activated.patch
    > sched-make_task_noninteractive_use_sleep_type.patch
    > sched-dont_decrease_idle_sleep_avg.patch
    > sched-include_noninteractive_sleep_in_idle_detect.patch
    > sched-remove-on-runqueue-requeueing.patch
    > sched-activate-sched-batch-expired.patch
    > sched-reduce-overhead-of-calc_load.patch
    > #
    > sched-fix-interactive-task-starvation.patch
    > #
    > # "strange load balancing problems": pwil3058@bigpond.net.au
    > sched-new-sched-domain-for-representing-multi-core.patch
    > sched-fix-group-power-for-allnodes_domains.patch
    > x86-dont-use-cpuid2-to-determine-cache-info-if-cpuid4-is-supported.patch

    strange as it may sound, all of these patches are fine with me. I really
    tried to find a questionable one (out of principle) but failed ;-)

    there are two main risk areas: smpnice and the interactivity changes.
    [multi-core support ought to be risk-free] ['risk' here means some 'oh
    sh*t' conceptual problem that could cause big head-scratching shortly
    before 2.6.17 is released, not some easy to fix regression.]

    Smpnice got alot of attention (and testing) and it's still a feature
    well worth having. The biggest risk comes from its relative complexity,
    but not doing the merge now wont reduce that risk. The biggest plus
    compared to the previous iteration is that smpnice is now essentially a
    NOP for same-nice-level workloads.

    The interactivity changes had less testing (being relatively young), but
    they are pretty well split up and they should solve the worst of the
    starvation problems. So if any of those causes problems, it will be an
    easy revert.

    All in one, i'm not worried about any these changes.

    > I'm not sure what the "Suresh had problems" comment refers to -
    > perhaps a now-removed patch.

    i think that got resolved with a retest.

    > afaik, the load balancing problem which Peter observed remains
    > unresolved.

    this seems resolved too.

    > Has smpnice had appropriate testing for regressions?

    it's all green again, and it seems all parties that reported regressions
    before retested and there are no outstanding complaints. Having it in
    -mm longer probably wont cause additional increase in test coverage. (in
    fact bitrot will probably degrade its test status, so i wouldnt wait any
    longer with it. We've got the spotlight on it now, so lets try it
    upstream while it's still hot and in tester's attention span.)

    Ingo
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2006-03-23 06:10    [W:6.267 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site