All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@osdl.org>
To: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
Cc: nickpiggin@yahoo.com.au, mingo@elte.hu, linux-kernel@vger.kernel.org
Subject: Re: [patch 0/2] fix perf. bug in wake-up load balancing for aim7 and db workload
Date: Mon, 13 Feb 2006 19:38:56 -0800	[thread overview]
Message-ID: <20060213193856.696bf1f0.akpm@osdl.org> (raw)
In-Reply-To: <200602140309.k1E394g17590@unix-os.sc.intel.com>

"Chen, Kenneth W" <kenneth.w.chen@intel.com> wrote:
>
> Commit d7102e95b7b9c00277562c29aad421d2d521c5f6 in linus's git tree
> 
> [PATCH] sched: filter affine wakeups
> From: Nick Piggin <nickpiggin@yahoo.com.au>
> Track the last waker CPU, and only consider wakeup-balancing if there's a
> match between current waker CPU and the previous waker CPU.  This ensures
> that there is some correlation between two subsequent wakeup events before
> we move the task.  Should help random-wakeup workloads on large SMP
> systems, by reducing the migration attempts by a factor of nr_cpus.
> 
> 
> Apparently caused more than 10% performance regression for aim7 benchmark.

Post-mortem time.   Why was it merged?

This patch was added to -mm on 8 November 2006.  Was merged into mainline
12 January 2006.  That's two months in -mm and one month in mainline.

I don't think it's reasonable to stretch the latency of scheduler patches
to even longer than three months and I doubt if that'll solve the problem.

Oh well, at least we found it.

> 
> We should back out the above commit and add a sysctl variable to control the
> behavior of load balancing in wake up path, so user can dynamically select
> a mode that best fit for the workload environment.  And kernel can achieve
> best performance in two extreme ends of incompatible workload environments.

Well I don't see any benchmark numbers in the original patch.  Just an
assertion that it "should" help something.

I'm more inclined to revert it and not add the sysctl (ugh) until we have a
good reason to do so.

  reply	other threads:[~2006-02-14  3:39 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-02-14  3:09 [patch 0/2] fix perf. bug in wake-up load balancing for aim7 and db workload Chen, Kenneth W
2006-02-14  3:38 ` Andrew Morton [this message]
2006-02-14  3:44   ` Nick Piggin
2006-02-14  3:57     ` Nick Piggin
2006-02-14  4:13       ` Andrew Morton
2006-02-14  3:59     ` Andrew Morton
2006-02-14  6:13     ` Chen, Kenneth W
2006-02-14  5:47   ` Chen, Kenneth W
2006-02-14  7:34   ` Ingo Molnar
  -- strict thread matches above, loose matches on Subject: below --
2006-02-14  7:46 Chen, Kenneth W
2006-02-14  8:00 ` Andrew Morton
2006-02-14 12:47   ` Ingo Molnar
2006-02-14 18:31     ` Chen, Kenneth W
2006-02-14  8:04 Chen, Kenneth W

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20060213193856.696bf1f0.akpm@osdl.org \
    --to=akpm@osdl.org \
    --cc=kenneth.w.chen@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=nickpiggin@yahoo.com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.