Introduction

I've been looking at the wake_affine path to improve the group scheduling case (wake affine performance for fair group sched has historically lagged) as well as tweaking performance in general.

The current series of patches is attached, the first of which should probably be considered for 2.6.38 since it fixes a bug/regression in the case of waking up onto a previously (group) empty cpu. While the others can be considered more forwards looking.

I've been using an rpc ping-pong workload which is known be sensitive to poor affine decisions to benchmark these changes, I'm happy to run these patches against other workloads. In particular improvements on reaim have been demonstrated, but since it's not as stable a benchmark the numbers are harder to present in a representative fashion. Suggestions/pet benchmarks greatly appreciated here.

Some other things experimented with (but didn't pan out as a performance win):
- Considering instantaneous load on prev_cpu as well as current_cpu
- Using more gentle wl/wg values to reflect that they a task's contribution to load_contribution is likely less than its weight.

Performance:

(througput is measured in txn/s across a 5 minute interval, with a 30 second warmup)

tip (no group scheduling):
throughput=57798.701988 reqs/sec.
throughput=58098.876188 reqs/sec.

tip: (autogroup + current shares code and associated broken effective_load) throughput=49824.283179 reqs/sec.
throughput=48527.942386 reqs/sec.

tip (autogroup + old tg_shares code): [parity goal post] throughput=57846.575060 reqs/sec. throughput=57626.442034 reqs/sec.

tip (autogroup + effective_load rewrite):
throughput=58534.073595 reqs/sec.
throughput=58068.072052 reqs/sec.

tip (autogroup + effective_load + no affine moves for hot tasks):
throughput=60907.794697 reqs/sec. throughput=61208.305629 reqs/sec.

Thanks,

- Paul