[lkml]   [2006]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: -mm seems significanty slower than mainline on kernbench
    Con Kolivas wrote:
    > On Thu, 12 Jan 2006 11:54 am, Peter Williams wrote:
    >>Peter Williams wrote:
    >>>Con Kolivas wrote:
    >>>>On Wednesday 11 January 2006 23:24, Peter Williams wrote:
    >>>>>Martin J. Bligh wrote:
    >>>>>>That seems broken to me ?
    >>>>>But, yes, given that the problem goes away when the patch is removed
    >>>>>(which we're still waiting to see) it's broken. I think the problem is
    >>>>>probably due to the changed metric (i.e. biased load instead of simple
    >>>>>load) causing idle_balance() to fail more often (i.e. it decides to not
    >>>>>bother moving any tasks more often than it otherwise would) which would
    >>>>>explain the increased idle time being seen. This means that the fix
    >>>>>would be to review the criteria for deciding whether to move tasks in
    >>>>Look back on my implementation. The problem as I saw it was that one
    >>>>task alone with a biased load would suddenly make a runqueue look much
    >>>>busier than it was supposed to so I special cased the runqueue that
    >>>>had precisely one task.
    >>>OK. I'll look at that.
    >>Addressed in a separate e-mail.
    >>>But I was thinking more about the code that (in the original) handled
    >>>the case where the number of tasks to be moved was less than 1 but more
    >>>than 0 (i.e. the cases where "imbalance" would have been reduced to zero
    >>>when divided by SCHED_LOAD_SCALE). I think that I got that part wrong
    >>>and you can end up with a bias load to be moved which is less than any
    >>>of the bias_prio values for any queued tasks (in circumstances where the
    >>>original code would have rounded up to 1 and caused a move). I think
    >>>that the way to handle this problem is to replace 1 with "average bias
    >>>prio" within that logic. This would guarantee at least one task with a
    >>>bias_prio small enough to be moved.
    >>>I think that this analysis is a strong argument for my original patch
    >>>being the cause of the problem so I'll go ahead and generate a fix. I'll
    >>>try to have a patch available later this morning.
    >>Attached is a patch that addresses this problem. Unlike the description
    >>above it does not use "average bias prio" as that solution would be very
    >>complicated. Instead it makes the assumption that NICE_TO_BIAS_PRIO(0)
    >>is a "good enough" for this purpose as this is highly likely to be the
    >>median bias prio and the median is probably better for this purpose than
    >>the average.
    > This is a shot in the dark. We haven't confirmed 1. there is a problem 2. that
    > this is the problem nor 3. that this patch will fix the problem.

    I disagree. I think that there is a clear mistake in my original patch
    that this patch fixes.

    > I say we
    > wait for the results of 1. If the improved smp nice handling patch ends up
    > being responsible then it should not be merged upstream, and then this patch
    > can be tested on top.
    > Martin I know your work move has made it not your responsibility to test
    > backing out this change, but are you aware of anything being done to test
    > this hypothesis?

    Peter Williams

    "Learning, n. The kind of ignorance distinguishing the studious."
    -- Ambrose Bierce
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-01-12 02:31    [W:0.029 / U:39.244 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site