[patch 0/2] fix perf. bug in wake-up load balancing for aim7 and db workload

["Chen, Kenneth W" <kenneth.w.chen@intel.com>]

Commit d7102e95b7b9c00277562c29aad421d2d521c5f6 in linus's git tree

[PATCH] sched: filter affine wakeups
From: Nick Piggin <nickpiggin@yahoo.com.au>
Track the last waker CPU, and only consider wakeup-balancing if there's a
match between current waker CPU and the previous waker CPU.  This ensures
that there is some correlation between two subsequent wakeup events before
we move the task.  Should help random-wakeup workloads on large SMP
systems, by reducing the migration attempts by a factor of nr_cpus.


Apparently caused more than 10% performance regression for aim7 benchmark.
The setup in use is 16-cpu HP rx8620, 64Gb of memory and 12 MSA1000s with
144 disks. Each disk is 72Gb with a single ext3 filesystem (courtesy of
HP, who supplied benchmark results).

The problem is, for aim7, the wake-up pattern is random, but it still needs
load balancing action in the wake-up path to achieve best performance. With
the above commit, lack of load balancing hurts that workload.

However, for workloads like database transaction processing, the requirement
is exactly opposite.  In the wake up path, best performance is achieved with
absolutely zero load balancing.   We simply wake up the process on the CPU
that it was previously run.  Worst performance is obtained when we do load
balancing at wake up.

There isn't an easy way to auto detect the workload characteristics.  Ingo's 
earlier patch that detects idle CPU and decide whether to load balance or not 
doesn't perform with aim7 either since all CPUs are busy (it causes even
bigger perf. regression).

We should back out the above commit and add a sysctl variable to control the
behavior of load balancing in wake up path, so user can dynamically select
a mode that best fit for the workload environment.  And kernel can achieve
best performance in two extreme ends of incompatible workload environments.

Two patches to follow.

- Ken

-
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/