[lkml]   [2003]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] HT scheduler, sched-2.5.68-A9
    Ingo, several questions.

    What makes this statement:

    * At this point it's sure that we have a SMT
    * imbalance: this (physical) CPU is idle but
    * another CPU has two (or more) tasks running.

    true? Do you mean "this cpu/sibling set are all idle but another
    cpu/sibling set are all non-idle"? Are we assuming that because both
    a physical processor and its sibling are not idle, that it is better to
    move a task from the sibling to a physical processor? In other words,
    we are presuming that the case where the task on the physical processor
    and the task(s) on the sibling(s) are actually benefitting from the
    relationship is rare?

    * We wake up one of the migration threads (it
    * doesnt matter which one) and let it fix things up:

    So although a migration thread normally pulls tasks to it, we've altered
    migration_thread now so that when cpu_active_balance() is set for its
    cpu, it will go find a cpu/sibling set in which all siblings are busy
    (knowing it has a good chance of finding one), decrement nr_running in
    the runqueue it has found, call load_balance() on the queue which is
    idle, and hope that load_balance will again find the busy queue (the
    same queue as the migration thread's) and decide to move a task over?

    whew. So why are we perverting the migration thread to push rather
    than pull? If active_load_balance() finds a imbalance, why must we use
    such indirection? Why decrement nr_running? Couldn't we put together
    a migration_req_t for the target queue's migration thread?

    Making the migration thread TASK_UNINTERRUPTIBLE has the nasty side
    effect of artificially raising the load average. Why is this changed?

    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.020 / U:10.008 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site