Re: Performance regression of specjbb2005/aim7 with 2.6.29-rc1

On Tue, 2009-01-13 at 16:57 +0800, Zhang, Yanmin wrote:
Comparing with 2.6.28's results, specjbb2005 has about 7% regression with 2.6.29-rc1
on my a couple of x86_64 machines. aim7 has about 1.7% regression.

Ming did a quick bisect with aim7 and located below patch.

commit 0a582440ff546e2c6610d1acec325e91b4efd313
Author: Mike Galbraith <efault@xxxxxx>
Date: Fri Jan 2 12:16:42 2009 +0100

sched: fix sched_slice()

Impact: fix bad-interactivity buglet

Fix sched_slice() to emit a sane result whether a task is currently
enqueued or not.

Signed-off-by: Mike Galbraith <efault@xxxxxx>
Tested-by: Jayson King <dev@xxxxxxxxxxxxxx>
Signed-off-by: Ingo Molnar <mingo@xxxxxxx>


After we revert the patch, aim7 regression disappeared. specjbb2005 regression becomes
less than 1.5% on 8-core stokley and disappears on 16-core tigerton. I don't know what
causes the last 1.5% regression.

As tbench has about 5% improvement and oltp(mysql+sysbench) has 5% improvement, we also tested
to make sure such improvement isn't related to above patch. volanoMark's improvement is also not
related to the patch. So it seems safe to revert it.

No, it's not safe to just revert. You can replace it with something
else, but as long as sched_slice() is called for unqueued tasks, it must
emit sane slices, otherwise you can experience a latency-hit-from-hell.

See thread: problem with "sched: revert back to per-rq vruntime"?

-Mike

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages