Messages in this thread Patch in this message | | | Date | Tue, 25 Sep 2012 20:42:45 +0200 | From | Borislav Petkov <> | Subject | Re: 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets - bisected |
| |
On Tue, Sep 25, 2012 at 10:21:28AM -0700, Linus Torvalds wrote: > On Tue, Sep 25, 2012 at 10:00 AM, Borislav Petkov <bp@alien8.de> wrote: > > > > 3.6-rc6+tip/auto-latest-kill select_idle_sibling() > > Is this literally just removing it entirely?
Basically yes:
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 6b800a14b990..016ba387c7f2 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -2640,6 +2640,8 @@ static int select_idle_sibling(struct task_struct *p, int target) struct sched_group *sg; int i; + goto done; + /* * If the task is going to be woken-up on this cpu and if it is * already idle, then it is the right target. > Because apart from the latency spike at 4 procs (and the latency > numbers look very noisy, so that's probably just noise), it looks > clearly superior to everything else. On that benchmark, at least.
Yep, I need more results for a more reliable say here.
> How does pgbench look? That's the one that apparently really wants to > spread out, possibly due to user-level spinlocks. So I assume it will > show the reverse pattern, with "kill select_idle_sibling" being the > worst case.
Let me run pgbench tomorrow (I had run it only on an older family 0x10 single-node box) on Bulldozer to check that out. And we haven't started the multi-node measurements at all.
> Sad, because it really would be lovely to just remove that thing ;)
Right, so why did we need it all, in the first place? There has to be some reason for it.
Thanks.
-- Regards/Gruss, Boris.
| |