Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected

Linus Torvalds
2012-09-24T15:53:10Z

On Mon, Sep 24, 2012 at 8:30 AM, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> No idea if its sufficient, but its a start.

Can we please do this too?

diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index 96e2b18b6283..2010c1ece7b3 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -2634,25 +2634,12 @@ find_idlest_cpu(struct sched_group *group,
struct task_struct *p, int this_cpu)
*/
static int select_idle_sibling(struct task_struct *p, int target)
{
- int cpu = smp_processor_id();
- int prev_cpu = task_cpu(p);
struct sched_domain *sd;
struct sched_group *sg;
int i;

- /*
- * If the task is going to be woken-up on this cpu and if it is
- * already idle, then it is the right target.
- */
- if (target == cpu && idle_cpu(cpu))
- return cpu;
-
- /*
- * If the task is going to be woken-up on the cpu where it previously
- * ran and if it is currently idle, then it the right target.
- */
- if (target == prev_cpu && idle_cpu(prev_cpu))
- return prev_cpu;
+ if (idle_cpu(target))
+ return target;

/*
* Otherwise, iterate the domains and find an elegible idle cpu.

(obviously whitespace-damaged). The whole "let's test prev_cpu or cpu"
seems stupid and counter-productive. The only possible values for
'target' are the two we test for.

Your patch looks odd, though. Why do you use some complex initial
value for 'candidate' (nr_cpu_ids) instead of a simple and readable
one (-1)?

And the whole "if we find any non-idle cpu, skip the whole domain"
logic really seems a bit odd (that's not new to your patch, though).
Can somebody explain what the whole point of that idiotically written
function is?

Linus