Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to3.6-rc5 on AMD chipsets - bisected

[Linus Torvalds]

On Mon, Sep 24, 2012 at 8:30 AM, Peter Zijlstra <a.p.zijlstra@xxxxxxxxx> 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
--
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/