lkml.org 
[lkml]   [2004]   [Mar]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Lse-tech] [patch] sched-domain cleanups, sched-2.6.5-rc2-mm2-A3
    >> Exec time balancing is a *lot* more efficient, it just doesn't work
    >> for things that don't exec ... cloned threads would certainly be one
    >> case.
    >
    > yeah - exec-balancing is a clear thing. fork/clone time balancing is
    > alot less clear.

    OK, well it *looks* to me from a quick look at your patch like
    sched_balance_context will rebalance at both fork *and* exec time.
    That seems like a bad plan, but maybe I'm misreading it.

    Can we hold off on changing the fork/exec time balancing until we've
    come to a plan as to what should actually be done with it? Unless we're
    giving it some hint from userspace, it's frigging hard to be sure if
    it's going to exec or not - and the vast majority of things do.

    There was a really good reason why the code is currently set up that
    way, it's not some random accident ;-)

    Clone is a much more interesting case, though at the time, I consciously
    decided NOT to do that, as we really mostly want threads on the same
    node. The exception is the case where we have one app with lots of threads,
    and nothing much else running on the system ... I tend to think of that
    as an artificial benchmark situation, but maybe that's not fair. We
    probably need to just do a more conservative version of the cross-node
    rebalance at fork time.

    M.

    -
    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: 2005-03-22 14:01    [W:0.028 / U:29.592 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site