Messages in this thread | | | From | Linus Torvalds <> | Date | Mon, 24 Sep 2012 08:52:45 -0700 | Subject | Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected |
| |
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
| |