[lkml]   [2003]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] HT scheduler, sched-2.5.68-B2
    >>> >  - turn off the more agressive idle-steal variant. This could fix the
    >>> > low-load regression reported by Martin J. Bligh.
    >>> Yup, that fixed it (I tested just your first version with just that
    >>> bit altered).
    >> Can we make this an arch specific option? I have a feeling the HT performance
    >> on low loads will actually drop with this disabled.

    Actually, what must be happening here is that we're agressively stealing
    things on non-HT machines ... we should be able to easily prevent that.

    Suppose we have 2 real cpus + HT ... A,B,C,D are the cpus, where A, B
    are HT twins, and C,D are HT twins. A&B share runqueue X, and C&D share
    runqueue Y

    What I presume you're trying to do is when A and B are running 1 task
    each, and C and D are not running anything, balance out so we have
    one on A and one on C. If we define some "nr_active(rq)" concept to be
    the number of tasks actually actively running on cpus, then if we we're
    switching from nr_actives of 2/0 to 1/0.

    However, we don't want to switch from 2/1 to 1/2 ... that's pointless.
    Or 0/1 to 1/0 (which I think it's what's happening). But in the case
    where we had (theoretically) 4 HT siblings per real cpu, we would want
    to migrate 1/3 to 2/2.

    The key is that we want to agressively steal when
    nr_active(remote) - nr_active(idle) > 1 ... not > 0.
    This will implicitly *never* happen on non HT machines, so it seems
    like a nice algorithm ... ?


    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: 2005-03-22 13:34    [W:0.021 / U:82.992 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site