Re: [patch] HT scheduler, sched-2.5.68-A9

[Rick Lindsley <ricklind@us.ibm.com>]

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?

Rick